Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Object Keys #13

Open
coderingo opened this issue Feb 1, 2017 · 2 comments
Open

Inconsistent Object Keys #13

coderingo opened this issue Feb 1, 2017 · 2 comments

Comments

@coderingo
Copy link

Hi,

Thanks for the great library. Due to limitation of time, I am not able to submit a pull request but I think its worth raising an issue here. The Keys of the Object created from the data are directly pulled from the HTML. So for example if a user is using itemprop="Description" then it will add Description as key to microdata but if a user is using itemprop="description" then it will use the lowercase description key.

Although the burden of using a valid schema with proper cases lie on the webmaster of the site, It will be nice if WAE can transform the keys before adding them into the object.

Currently I add a fix to my code by using then following recursive function:

const _ = require('lodash'); const lowerCaseKeys = function (obj) { return _.transform(obj, (result, value, key) => { let k = key; if (_.isString(key)) { k = key.toLowerCase(); } if (_.isObject(value) || _.isArray(value)) { result[k] = this.lowerCaseKeys(value); } else { result[k] = value; } }, []); },

I use it for small objects so its not a problem for me yet but if anyone else wish to use it, be cautious as it creates a stack for every iteration. If the keys get modified before being added to the object then it will eliminate extra processing like above.

I am happy to help further if the Library Owner wants/needs.

@Vasanth-Indix
Copy link

@coderingo : Thanks for your support to the library.

Reg. the case sensitivity issue of object keys, the fix would be to map the keys parsed from the page to property names defined in Schema.org (Eg: http://schema.org/Offer).

Such mapping is to be used to generate the object. The mapping ensures that the keys are always camel-casing.
This solution mean that the library goes into strict mode. If any typo is made in the itemprop names used the website, such itemprop will be ignored.

Whether to go strict mode or not can be config driven and can be fed in as input to the library.

Does the solution sound fine?

@coderingo
Copy link
Author

Hi Vasanth,

The solution Looks perfectly fine and more "standardized" to me. I am looking forward to updates on it and if I got time, I will start working on a pull request too.

Kind Regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants