Entity adapter methods do not cause TS errors when used as case reducers illegaly

[markerikson]

Per https://codesandbox.io/s/entityadapter-test-o5190 , savedQueriesSliceScoped.ts has a state slice with two different normalized sections inside of it: {public: EntityState, private: EntityState}.

That means that passing someAdapter.updateMany as a case reducer should be illegal and cause a TS error, because the adapter methods should only be getting an EntityState object as the state argument. Instead, TS doesn't seem to error.

If I manually write a reducer and call that same update method inside, TS correctly flags it as being illegal:

const { actions, reducer } = createSlice({
  name: "savedQueriesScoped",
  initialState: initialSavedQueriesState,
  reducers: {
    // This line should cause errors, but doesn't
    savedQueriesUpdated: savedQueriesAdapter.updateMany,
    otherReducer(state, action: PayloadAction<KustoQueryDefinition[]>) {
      // the `state` arg here will be flagged as an error
      savedQueriesAdapter.updateMany(state, action);
    }
  },

@phryneas , any ideas?

[phryneas]

I just took a quick look.

Used in this position in reducers, S in

declare interface EntityStateAdapter<T> {
    addOne<S extends EntityState<T>>(state: S, entity: T): S;

seems to somehow resolve to any or somewhat similar, making it usable everywhere.

A possible solution would probably be to write it more complicated, eliminating any and enforcing EntityState<T> at the least, like

type IgnoreAny<T> = IsAny<T, unknown, T>;

declare interface EntityStateAdapter<T> {
    addOne<S extends EntityState<T>>(state: IgnoreAny<S> & EntityState<T>, entity: T): IgnoreAny<S> & EntityState<T>;

Something a little simpler like

type FallbackIfAny<T, Fallback = unknown> = IsAny<T, Fallback, T>;

declare interface EntityStateAdapter<T> {
    addOne<S extends EntityState<T>>(s: FallbackIfAny<S, EntityState<T>>, entity: T): FallbackIfAny<S, EntityState<T>>;

also seems to do the trick.

This just as a first feedback, might need a little more investigation later.

[markerikson]

Should be fixed by #436 .