Skip to content

Update knockout.dirtiable.js#3

Open
nenitiko wants to merge 1 commit intoAreson:masterfrom
nenitiko:master
Open

Update knockout.dirtiable.js#3
nenitiko wants to merge 1 commit intoAreson:masterfrom
nenitiko:master

Conversation

@nenitiko
Copy link

This is actually a mixed-up version of Ryan's and your work. From Ryan's implementation I took the dirty-able functionality from you I took the interface, the extender and the initiative. One of the problems I found with your implementation was that once an object was made dirty there was no turning back, it stayed dirty even when changing all properties to their initial values, for example if you track an Array and add an item, it is marked was dirty but if you removed that same item, it wont go back to non-dirty state. Ryan's work supports that.

This is actually a mixed-up version of Ryan's and Areson's work. From Ryan's implementation I took the dirty-able functionality from you I took the interface, the extender and the initiative. One of the problems I found with your implementation was that once an object was made dirty there was no turning back, it stayed dirty even when changing all properties to their initial values, for example if you track an Array and add an item, it is marked was dirty but if you removed that same item, it wont go back to non-dirty state. Ryan's work supports that.
@Areson
Copy link
Owner

Areson commented Feb 11, 2015

Ack! It's been a while since I looked over this. You are correct about it not "turning back", but one thing I didn't like was the fact that we had to always parse out the object to JSON every time a change was made to it, as this was potentially rather expensive. As a compromise, I simply said that once it was dirty, it stayed dirty. This allows us to skip re-creating the JSON, which would be necessary if we wanted the object to pop back to clean if it reverted to its initial state.

With the changes you've proposed, you actually don't need the "_isInitiallyDirty" value, as it isn't set to anything other than "false", and simply have the extension rely on looking at the JSON.

I think an ideal setup would be to have a second argument for the extension that let's you toggle between a "deep" dirty tracking (which would revert back to clean if we went back to the initial state) or a "simple" dirty tracking which would not revert. This would give you flexibility based on your performance and application needs.

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