Port ngrx/entity and add createAsyncThunk

[markerikson]

Per #76 and #333 , I've decided that there is a lot of potential benefit in having an official minimal solution for dealing with the most common data fetching and normalized data storage scenarios.

To that end, I've ported https://ngrx.io/guide/entity to Redux Toolkit, but with a bunch of changes:

• Rewrote the internals to use Immer and simplify the logic
• Reordered the arguments to the generated EntityAdapter methods to take state first and also feature-detect PayloadActions, so that they can be used directly as Redux case reducers

(I'd hoped that @ngrx/entity might be made more generic so it could be used by both NgRx and RTK, but the changes I ended up making are too drastic.)

I've also added a createAsyncThunk function as originally written in #76 (comment) .

This should allow usage patterns like:

const usersAdapter = createEntityAdapter();

const fetchUsers = createRequestAction(
    "users/fetch",
    () => usersAPI.fetchAll()
);

// `fetchUsers` is now a typical thunk action creator, but also has
// four more action creators attached:
// pending, fulfilled, finished, rejected
// it will automatically dispatch those based on the promise lifecycle

const usersSlice = createSlice({
    name: "users",
    initialState: usersAdapter.getInitialState(),
    reducers: {
        userAdded: usersAdapter.addOne,
        userRemoved: usersAdapter.removeOne,
        // etc
    },
    extraReducers: {
        // would also want to handle the loading state cases, probably with a state machine,
        // using the lifecycle actions attached to fetchusers
        [fetchUsers.fulfilled](state, action) {
            return usersAdapter.upsertMany(state, action.payload.result)
        }
    }
});

Published it as https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0-alpha.0

[netlify]

Deploy preview for redux-starter-kit-docs ready!

Built with commit 0252d80

https://deploy-preview-352--redux-starter-kit-docs.netlify.com

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[markerikson]

I'm already not happy with how createAsyncThunk is passing in values to the generated action creators. I'd rather use prepare callbacks so that they're called like fulfilled(result, args), and we get {type: "someData/fulfilled", payload: result, meta: {args}), rather than payload: {result, args}. That way we can reuse the entity adapter methods and directly handle the results because they're in the payload.

[markerikson]

I removed the removeMany(predicate) overload since we discourage passing functions in through actions, and I don't want to have folks trying to do that when it's used as a reducer. Straightforward enough to calculate the list of IDs to remove yourself.

I also reworked the thunk actions to put the thunk args in as action.meta.args.

Unfortunately, I realized that before releasing alpha.0, my attempt to put all the fetch callback parameters into an options object probably broke the ability to correctly infer the type of the args param correctly (ie, what the user is supposed to pass into the thunk as they're dispatching it). Also, the inferred types are incredibly long and hard to read.

@phryneas , can you take a look at those issues? I'm getting over my head trying to make changes there.

[lacolaco]

As far as I understood, I feel users/fetch doesn't seem following the redux style guide.
https://redux.js.org/style-guide/style-guide/#model-actions-as-events-not-setters

Is fetch an event? Should I choose users/fetched rather?
I'd like to know the thought about the recommendation of async actions.

[markerikson]

@lacolaco : I'm not worried about style guide stuff atm. I'm just trying to get the API working the way I want it to, and throwing together small snippets to try to exercise the code. Don't read anything into the action type names in the tests, they're not relevant or an official guidance.

[lacolaco]

@markerikson I see, thank you. Instead, I leave the same comment on the original issue.

[phryneas]

Okay, gave the entities a read. I like it, it stikes a nice balance. But I've annotated a few questions along the way.

[phryneas]

This doesn't make sense to me. From how I read it, this will be passed to Array.prototype.sort - and the callback presented there should always return a number?

[markerikson]

Yeah, the Array.sort() signature clearly says the result is a number (which of course should be 1/0/-1). Good catch!

[LMFinney]

I'm late to the party, but I noticed that bug in NgRx a few weeks ago, and it has since been removed.

[github-actions]

Size Change: +14.9 kB (26%) 🚨

Total Size: 56.7 kB

Filename	Size	Change
dist/redux-toolkit.cjs.development.js	7.77 kB	+3.57 kB (45%)	🚨
dist/redux-toolkit.cjs.production.min.js	3.79 kB	+1.69 kB (44%)	🚨
dist/redux-toolkit.esm.js	7.58 kB	+3.55 kB (46%)	🚨
dist/redux-toolkit.umd.js	27.1 kB	+4.33 kB (16%)	⚠️
dist/redux-toolkit.umd.min.js	10.4 kB	+1.71 kB (16%)	⚠️

ℹ️ View Unchanged

Filename	Size	Change
dist/index.js	149 B	0 B

_{compressed-size-action}

[markerikson]

At this point I think I feel pretty good about the overall shape of the APIs.

I'm going to go ahead and merge this PR into the v.1.3.0-integration branch. If we do have any more tweaks, we can make them there.

Next step will be to start working on porting redux-immutable-state-invariant over.