-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[FEATURE ds-rollback-attribute] Add rolling back of a single model attribute #4246
Conversation
@@ -435,6 +435,7 @@ InternalModel.prototype = { | |||
this.record._notifyProperties(dirtyKeys); | |||
|
|||
}, | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably don't want to introduce additional whitespace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, all other methods in this file have whitespace separators, so I left it in as a small style fix.
Basically 👍 to the feature! My gut feeling says that this should be handled via the state machine though. Take for example the case where a record in in the invalid state and a property is reset: in this case the corresponding error is removed and the record could become valid. Not sure if there are other cases, but inFlight might also be a noteworthy scenario, as you @courajs already said. I hope that I have time this weekend to take a deeper look. Will keep you posted! |
Hey @courajs, finally I have time to get back to you here. I am very sorry for the delay 😔. This has been discussed in the team meeting and we agreed that this functionality would be useful. We think that naming the method Can you update this PR and:
Thanks for your work so far! Looking forward to getting this merged! |
this.send('propertyWasReset', attributeName); | ||
this.record.notifyPropertyChange(attributeName); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To leave all the logic to the state machine I would suggest adding a new method to the InternalModel
which returns the latest truth for an attribute: either the inFlight value or the canonical value. Then, in DS.Model#resetAttribute
we simply get the latest value from the internal model and set
it. By this everything should basically behave the same as if the attribute would be reset manually to the latest value...
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion!
@pangratz Sounds good to me |
@courajs kindly asking if you had any chance of getting this up to date? I would love to see this feature in |
@pangratz Thanks for the ping! This is mostly updated now, but I bumped into an existing bug with in-flight records we need to fix first. I'll have a PR for that soon and I'll link it here |
c5a8a0b
to
3382029
Compare
I believe this build only failed because of #4379, and when it's merged these tests will pass |
Confirmed locally, a rebase on top of #4379 and the tests pass. |
3382029
to
1776449
Compare
@pangratz I think we're pretty much good here! Any final feedback? |
I meant to review but got caught up in work. I will try to review not later than |
sounds good :) |
@method latestTrueValue | ||
@private | ||
*/ | ||
InternalModel.prototype.latestTrueValue = function latestTrueValue(key) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though this is an internal method, I am not not too happy about the name here to be honest. Coming up with a better one is difficult though 😔 What do you think of lastPreassignedAttributeValue()
or even lastCanonicalOrInFlightAttributeValue()
or something? I know this is a tiny nitpick, but I was hoping we find a better name here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could settle for lastCanonicalOrInFlightAttributeValue
. What about latestSavedValue
or latestComittedValue
? Since it's not necessarily canonical yet, but it's trying to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to favor the - admittedly verbose but expressive - lastCanonicalOrInFlightAttributeValue
. We can change that always later once we find a better name...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use lastAcknowledgedValue
here. This should be clear enough.
Overall, this looks very good 🚀 Some few additions and this is ready to
Thanks! |
👍 |
38545cf
to
c372bb4
Compare
@pangratz updated! |
This just needs a rename for the |
Whoops! I thought I did that rename 😅 |
@courajs how is this feature going? |
Just needs the rename mentioned above and a rebase when I get a chance |
c372bb4
to
f66a75b
Compare
@pangratz updated! |
f66a75b
to
6d510d3
Compare
6d510d3
to
9cb1b33
Compare
@pangratz I think we're finally ready for a merge here. Look good? |
Awesome! Thanks for the hard work on this @courajs 🚀 🎉 |
First pass at #3705
First feature PR!
Is there any subtlety around in-flight records that I'm missing?