Roadmap: RTK v1.3.0

[markerikson]

v1.3.0 is shaping up to be a somewhat sizeable set of changes:

• Adding createAsyncThunk and createEntityAdapter
• Porting redux-immutable-state-invariant over
• Dropping support for TS <3.5
• Possibly dropping or cloning the redux-devtools-extension package to see if we can improve shakeability? (or maybe things can get improved upstream)
• See if Immer drops a new version that tree-shakes better and we can use

Also, we should totally try to use https://github.com/mweststrate/import-size to help improve our shaking and bundle size.

Sketch of tasks to do:

• Code
  • Port redux-immutable-state-invariant
  • Look into porting redux-devtools-extension
  • Any further desired tweaks to createAsyncThunk and createEntityAdapter
    • createAsyncThunk error handling finalized and documented
  • Actually wait for Immer 6 release ( feature: optimize Immer bundling immerjs/immer#536 , Possible improvements to tree shaking and bundle size immerjs/immer#500 , add 5.0.2 type definitions as fallback for TS<3.7 immerjs/immer#541 )
  • Review bundle size info and try to shrink things
  • Export additional entity types for external usage
• Write at least one small-ish example app, both to confirm how the API feels in practice and to act as an example
• Docs
  • Add usage guides for new APIs
    • createAsyncThunk: data fetching in general, standard Redux patterns, how this simplifies
    • createEntityAdapter: normalization in general, a couple recipes for how you could do normalizing yourself and then use these methods to process (like calling normalizr in an action creator, and having a slice check for action.payload.entities.users and process accordingly)
  • Polish API reference pages
  • Cover new APIs in "Usage with TypeScript" page
  • Consider reworking tutorials to use new APIs?
  • Update README and other docs pages to add mentions of new APIs and revise information (per README, we do now have something for entities, just not relationships...)
  • Separate docs pages for the immutable and serialization middleware
• Update CRA templates to point to rtk@^1.3.0

Ongoing v1.3.0 integration work is in this PR:

v1.3.0 integration

[phryneas]

Additionally:

• give the entity adapter typings a thorough review (I just skimmed them so far)

[chybisov]

@markerikson how about using keys instead of ids? We already using entity and entities, so I think we should follow common datastore Entities, Properties, and Keys naming. What do you think?

[markerikson]

@chybisov : I'm not sure what you mean by "common naming".

The @ngrx/entity API already has state.entities and state.ids, which I like better than the docs page I wrote suggesting state.byId and state.allids:

https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape

So no, I don't see any reason to change that.

[chybisov]

@markerikson I mean standard way to name such things. In database world we have entities and keys to this entities. Pretty straightforward names. Key is more generic name, than id, it would be better.

btw @ngrx/entity already uses keys as variable name in a lot of place, I don't know why they not change the main one. I think most people just don't care :) but for consistency it would be just great.

[markerikson]

I feel like id is more relevant, given that we're also assuming the values have entity.id to begin with. Not planning to change that.

[markerikson]

I'm inclined to punt on the new Immer version for now. Whenever it comes out, it's probably worth its own separate update, probably 1.4.0. Removing that from the list.

[markerikson]

Throwing this here for now because I don't want to open another issue atm. Someone on Reddit showed some interesting notional syntax for generating async action types inside of createSlice:

https://www.reddit.com/r/reactjs/comments/f7ue0y/getting_started_with_the_official_redux_template/fiibthh/

https://i.imgur.com/kcJUcxd.png

const someSlice = createSlice({
    name: "slice",
    initialState,
    reducers: {
        fetchItems: {
            success(state, action) {}
        }
    }
})

Not sold on it, but it does go along with us already having an object notation for prepare callbacks. Worth noting.

[Brodzko]

Not sold on it, but it does go along with us already having an object notation for prepare callbacks. Worth noting.

I'd +1 this suggestion - personally using sagas and no thunks and I ended up wrapping createAction so that the returned action creator returned plain "starting" action and had the creators equivalent to async stages as properties. Essentially ended up with creators like fetch(), fetch.pending(), fetch.resolved(), fetch.rejected(), fetch.cancel().

I quite like how it feels in development, but my API is a tad bit awkward, not to mention I had to do the same thing with reducers (yeah, wrapping createSlice isn't easiest).

I'm pretty confident it could be done though, and having this as a core feature of RTK would be awesome for those of us who use sagas, observables or similar, instead of thunks :)

[CosmaTrix]

I love the entityAdapter! ❤️

I think that a couple more selectors could be added to it though. Namely selectOne and selectMany. It'd better map with the CRUD operations (where you have addOne, addMany, removeOne, etc...). Moreover, I think it would be useful in overall applications where you have a page listing all the entities and a details page displaying one entity.

What do you think?

[chybisov]

@CosmaTrix @markerikson it would be very useful, especially selecting some object by id or some other property.