-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[Table/EditableCell] Only update saved and dirty values if value changed #1651
Conversation
Only update saved and dirty values if value changedPreview: documentation | table |
this.setState({ savedValue: value, dirtyValue: value }); | ||
if (value !== this.props.value) { | ||
this.setState({ savedValue: value, dirtyValue: value }); | ||
} |
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.
Cool! Now, how do we unit-test this?
(Or more explicitly: can you add one?)
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.
Heh. It should be doable, I guess.
79f9d62
to
44b009c
Compare
Add testPreview: documentation | table |
expect(input.element).to.equal(document.activeElement); | ||
|
||
// edit | ||
input.change("my-changed-value"); |
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.
Whaaat is this glorious .change(...)
magic.
expect(onConfirm.called).to.be.false; | ||
expect(elem.find(".pt-editable-content").text()).to.equal("my-changed-value"); | ||
|
||
harness.mount( |
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.
So this is functionally equivalent to setProps
?
Fixes #1261
Changes proposed in this pull request:
We were updating saved and dirty value to match the value whenever any prop changed, no matter what. Even if
shouldComponentUpdate
would have returned false, becausecomponentWillReceiveProps
is always true. So if there were any changes made before rendering got there (because batched rendering), it'd reset those changes. Now this no longer happens.Reviewers should focus on:
Is
componentWillReceiveProps
even the right place for this? It apparently can't live incomponentWillUpdate
because that won't take asetState
, but... is there a better lifecycle spot for this?Or more generally: is there a better way to do what I'm doing?