Refactor deleteEntityRecord to use thunks instead of generators #34386
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adamziel
requested review from
ajitbohra,
chrisvanpatten and
nerrad
as code owners
|
Size Change: -1 B (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
noisysocks
approved these changes
Aug 31, 2021
| { __unstableFetch = null } = {} | ||
| ) { | ||
| const entities = yield getKindEntities( kind ); | ||
| { __unstableFetch = triggerFetch } = {} |
There was a problem hiding this comment.
Just a note so that we don't forget.
Right now __unstableFetch is so named because it's a "private" argument used only by the batch action. It would be nicer, I think, to remove the argument in favour of currying deleteEntityRecord, saveEntityRecord, etc. and only exporting a partial application.
We can't easily do this until everything uses thunks.
const createDeleteEntityRecordAction = ( fetch ) => ( kind, name, recordId, query ) => {
...
};
export const deleteEntityRecord = createDeleteEntityRecordAction( triggerFetch );There was a problem hiding this comment.
I really like that idea, it has some real Haskell vibes to it! :-)
There was a problem hiding this comment.
I paid $20k for a computer science degree and now I know how to use words like "currying" in a sentence.
jsnajdr
approved these changes
Aug 31, 2021
|
|
||
| yield removeItems( kind, name, recordId, true ); | ||
| await dispatch( removeItems( kind, name, recordId, true ) ); |
There was a problem hiding this comment.
Sync action that removes items from the in-memory cache in the store.
There was a problem hiding this comment.
I am still not on board with removing await when we dispatch a function call because it assumes we know the implementation details of that function. I think we're pretty close to having all the actions refactored though so maybe that would be enough to start the larger discussion? I have the resolvers in mind too, but maybe they're not a blocker for that.
There was a problem hiding this comment.
it assumes we know the implementation details of that function.
We only need to know the type of what the removeItems function returns. If that's a function (thunk) that returns a promise, we might want to await it. We already know what the parameters of removeItems are, and it's not an implementation details either.
adamziel
force-pushed
the
thunkify/deleteEntityRecord
branch
from
a6cba1f
to
7670420
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Builds on top of the thunks support added in #27276 and refactors just the parts of core-data required to make the
deleteEntityRecordwork (see #28389 from @jsnajdr).Test plan: