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

Remove dirty checks for objects #3596

Closed
wants to merge 30 commits into from

Conversation

kaste
Copy link
Contributor

@kaste kaste commented Apr 17, 2016

To come to an end here. Assembles the following PRs:

Then we can just remove the dirty check for object values 6d24b87.

Related #3343.

kevinpschaaf and others added 30 commits April 10, 2016 15:40
Note: `this[property] = value` implicitly guards against setting read
onlys. This check is now explicit.
Note: `set`'s third argument is unused within the library and should be
removed.

Note: No readOnly check here, why?

Note: Additional dirty check in accessors.html redundant.

Obvious code duplication between annotation effect and annotation path-
effect. Merge both?
Also opens `set` to set read-only properties. Note: computed properties
could be set as well. Nobody should do this.
That's harsh, but

  1. set() is a public method, so +1 for clean interface
  2. totally not used within the framework

Actually I think it was never used. For the record: could have been used
to set a path without notifying. (There is an equivalent arg for `_get` which
is used though during config.)
Removes _pathEffector override completely.
Replaces _notifyPathUp override.
Avoid dirty checking values, instead use a lock.
This reduces the addiction to dirty check values.
The general rule here is: `_forwardParentProp/Path` must assume fromAbove
is true; for `_forwardInstanceProp/Path` assume fromAbove is false.
…or-objects

# Conflicts:
#	src/standard/notify-path.html
…ty-checks-for-objects

# Conflicts:
#	src/lib/bind/accessors.html
…for-objects

# Conflicts:
#	src/lib/bind/accessors.html
#	src/standard/notify-path.html
#	test/unit/bind-elements.html
#	test/unit/bind.html
@kaste
Copy link
Contributor Author

kaste commented Apr 17, 2016

I think we should have these API changes/additions:

  • set(path, value, fromAbove?)
  • get(path)
  • notifyUpwards(path, value?) or propagateUpwards
  • assumeChanged(path, fromAbove?)

whereby path can be simple or deep (foo, foo.bar)

@devinivy
Copy link

@kaste I see that many of your ideas, this one included, made their way into the implementation of v2. Just wanted to say thanks!

@TimvdLippe
Copy link
Contributor

As @devinivy pointed out your suggestions have been adopted and are available in Polymer 2 as the MutableData mixin. Thanks!

@TimvdLippe TimvdLippe closed this Aug 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants