Is `createEntityAdapter` will be a standalone package ??

[carere]

First of all, thanks for this amazing library.

I think that everything is in the question 😄

[markerikson]

Ah... no, we have no plans to split any of RTK's APIs into other packages.

Can I ask what your concern is, or reason for asking?

FWIW, if you only need specific functions from Redux Toolkit, everything else should tree-shake out, so your bundle will only include what you use. The exception to this is that due to the way we import and initialize Immer, when you import any function from RTK, it will cause Immer to be included in your bundle. (But, createReducer/createSlice/createEntityAdapter all use Immer inside, so normally you need that anyway.)

[carere]

Yes, I'm using Redux toolkit with Rematch in Rescript, since it's easier to create bindings for rematch model vs toolkit slice, and the dispatch object from rematch. Another problem is the thunk which is a function that can also be an object, which is normal in JS, but not authorize in a strongly typed langage.

Finally I tree-shake what i use from redux toolkit (createEntityAdapter & createSelector & miniSerialize), so it's not important to release entity adapter as standalone 😄

I think we can close this one, and thank you for the quick answer :)

[markerikson]

Okay, I'll close it.

That said: @carere - I'm actually very curious what specific parts of Rematch's API you prefer over RTK. Could you give some more details? Also, what "problems with thunks" are you referring to? (We use thunks with RTK +TS all the time, so there shouldn't be any issues there.)

[carere]

Hey, first of all, I'm using Rescript which is a staticly and strongly typed langage, like Ocaml of F#.

Even so, it compiles to JS, when we write some bindings in order to use JS lib in Rescript, we cannot model every capabilities of JS unlike in TS. In my opinion, it's a win because, we have a better type system without the JS/TS flaws (null, undefined, any, etc).

So I prefer Rematch, for the way they handle the dispatch side of redux. In rematch, it's an object with models's name as key, and dictionnay of respective reducers / effetcs (replace thunk) as values. What I means, when saying "problems with thunks", is that in Rescript, it's difficult to write binding for a function which can have properties (which is trivial in JS since everything is object). Ans it's the case of the return of createAsyncThunk.

Rescript differs from TS (since their slogan is : Javascript with types, they have to cover every capability of JS). When using rescript, we want the security os strongly type system and the feature of FP langage (ADT, pattern matching, pipe operator, etc) but we also want to stay in the JS ecosystem 😄

I hope it's clear (I'm not a native english speaker 😓)

[phryneas]

And it's the case of the return of createAsyncThunk.

Couldn't you just write a wrapper in JS that returned the function and the properties on it separately - and then write bindings for that?

[markerikson]

Huh, that's a pretty rare combination :) I'm not sure I've even talked to anyone using Rescript + Redux before, tbh. So yeah, not really any advice I can offer from my side.