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

domData get and set #317

Closed
wants to merge 4 commits into from
Closed

domData get and set #317

wants to merge 4 commits into from

Conversation

diegonvs
Copy link
Contributor

No description provided.

@diegonvs diegonvs changed the base branch from master to develop November 30, 2017 17:37
@diegonvs diegonvs changed the title Improving tests for set and get domData get and set Nov 30, 2017
@diegonvs diegonvs mentioned this pull request Nov 30, 2017
* @return {!Object}
*/
static get(element, name, initialValue) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @diegonvs,

I don't think we should remove any functionality from the get method, since that will be a breaking change (even if we account for our own use cases it might break somewhere else).

Can we maintain the initialValue argument, and maybe just call the new set method from inside get if the arg is passed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point @Robert-Frampton , i think in the get method there could be no creation or editing of domData but thinking so as not to break API, this makes sense.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're leaving the API alone for get, we should also leave all the instances of it alone in metal. For example, 41756bc should just be left using get.

if (!element[METAL_DATA]) {
element[METAL_DATA] = {};
}
if (!name || !value) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this check prevent someone from passing a falsy value?

domData.set(element, 'foo', true)
// foo === true
domData.set(element, 'foo', false)
// foo === true

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll correct this!

@diegonvs
Copy link
Contributor Author

What do you guys think about the has method?
Key value may be 0 or "" and in this implementation will return false, i think that is broken, can i fix it?

@robframpton
Copy link

Hey @diegonvs, I think the has method only checks to see if the METAL_DATA object exists. So the values shouldn't have any affect on the return value.

return !!element[METAL_DATA];

@robframpton
Copy link

Hey @diegonvs,

At some point today we'll be cutting a release. Not trying to rush you, but what's your estimate for finishing this PR?

@robframpton
Copy link

Closing in favor of #319

@robframpton robframpton closed this Dec 1, 2017
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

Successfully merging this pull request may close these issues.

2 participants