-
-
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
[FEAT BUGFIX] enable canonical state updates to deleted records #5408
Conversation
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.
LGTM sans the try/catch within the test's run
tests/unit/model-test.js
Outdated
} | ||
}) | ||
} catch (e) { | ||
assert.ok(false, e); |
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.
what does this try/catch achieve?
tests/unit/model-test.js
Outdated
set(record, 'isArchived', true); | ||
assert.ok(false, 'Was unable to dirty a deleted record'); | ||
} catch (e) { | ||
assert.ok(true, e.message); |
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 assert the specific error rather than merely that there was an error
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.
Will do
tests/unit/model-test.js
Outdated
} | ||
}); | ||
} catch (e) { | ||
assert.ok(false, e); |
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.
what does this try/catch achieve?
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 think I can use expectAssertion
here instead
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.
@hjdivad oh wait, actually, I can't unless there's a corollary? I basically want a "expect no assertion"
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.
❤️
resolves #4995
replaces #5231
Problem
Records in the
root.deleted.saved
state currently error if new data is received from the server for the record while the record is still in the store.For instance, a user may desire the following flow, which is now possible with this PR:
Use Case
Sometimes deletions are "soft deletes", and sometimes deletions may be queued on the server and the deleted state not reflect immediately in other requests.
2.13 Regression
Prior to 2.13 we would unload records whose deletion had been persisted. While this enabled folks to push server updates back into the store for either use case above, this would create a new record in the
root.loaded.saved
state, which is also unexpected.This Fix
This fix enables canonical (but not dirty) state updates to
root.deleted.saved
records to still occur. Records are still available to the UI until the user opts to callunloadRecord
. This means that end users may themselves decide whether they want to unload and treat these records asundeleted
again, or maintain the deleted state.Soft Delete
User's desiring
soft delete
akaarchiving
with the ability to resurrect a model should not be usingdeleteRecord
ordestroyRecord
. While this PR will make soft-deletions via this mechanism work slightly better up until the point that resurrection is desired, users should instead fire an action to update a flag of their own making, and only fire a DELETE for a permanent deletion.