[Types] Strictly typed store allows invalid values

[xzilja]

I might be missing something, but shouldn't following disallow invalidA and invalidB values to be used in a store? As it is at the moment I don't get any error about them.

import create from 'zustand';

interface Store {
  count: number;
  increase: () => void;
}

const [useStore] = create<Store>(set => ({
  count: 0,
  invalidA: 0,
  increase: () => set(state => ({ count: state.count + 1 })),
  invalidB: () => set({ count: 0 })
}));

export default useStore;

[JeremyRH]

I don’t understand why TypeScript does this. You can experiment with the behavior here.

Here's a workaround:

const [useStore] = create<Store>((set): Store => ({ // additional type declaration
  count: 0,
  invalidA: 0, // errors
  increase: () => set(state => ({ count: state.count + 1 }))
}));

[clawoflight]

I assume that this is due to the structural/duck typing - any superset of Store is assignable to Store because it has all properties of Store?

[JeremyRH]

You're right. I learned it has to do with structural typing. Excess properties are allowed with structural typing. TypeScript does have excess property checking but it's only when explicitly defining an object of a specific type. Here is a good article about it:
https://medium.com/@lemoine.benoit/why-does-typescript-sometimes-fails-to-type-check-extra-properties-fd230ebbc295

[dai-shi]

I think this is resolved.

[csr632]

I got some typescript issue. Zustand can't infer the type of State from my creator. Example: https://codesandbox.io/s/test-zustand-74jze?file=/src/App.tsx

export function createItem(name: string) {
  const api = create((set) => {
    return {
      name,
      count: 1,
      setName: (newName: string) => {
        // set((prev) => {
        //   // prev
        // });
      }
    };
  });

  console.log(api.getState().invalid); // expect this line to trigger ts error, but it doesn't
}

[dai-shi]

@csr632 Yeah, I noticed that too and it's annoying for me personally.
I guess it's because of recursive type definition and TS can't infer types. We need TS experts help on it.

If you remove set, the store type will be inferred as you expect.

export function createItem(name: string) {
  const api = create(() => {
    return {
      name,
      count: 1,
      setName: (newName: string) => {
        // set((prev) => {
        //   // prev
        // });
      }
    };
  });

Only solution I have now is to manually type state: https://codesandbox.io/s/test-zustand-forked-mo5rs

[csr632]

Maybe related to this ts design limitation: microsoft/TypeScript#25092 (comment)

Could we re-design zustand's API so that it doesn't encourage user to write "context-sensitive function"?

const api = create((set) => { // this is a context-sensitive because it has untyped function parameters ”set“
    return {
      name,
      count: 1,
    };
  });

[dai-shi]

I'm not sure if I understand the term context-sensitive function.
Could we do anything without a breaking change?

[csr632]

I'm not sure if I understand the term context-sensitive function.

As microsoft/TypeScript#25092 (comment) said:

• a context-sensitive function is a function with untyped function parameters
• ts can't infer type from a context-sensitive function

In this case:

const api = create((set) => { // this is a context-sensitive because it has untyped function parameters ”set“
    return {
      name,
      count: 1,
    };
  });

So create can't infer any type infomation from the function.

Could we do anything without a breaking change?

Yes, we should never use the params:

const api = create(() => { // this is NOT a context-sensitive function because it doesn't list any params
   // we should never use the params
    return {
      name,
      count: 1,
      setName: (newName: string) => {
        // we use `api.set` instead of the `set` from param
        api.setState((prev) => ({
          count: prev.count + 1
        }));
      }
    };
  });

Checkout codesandbox.

But I think this is somehow ugly...

[dai-shi]

Thanks. I got it. That's what I noted recursive type definition. Now I learned the proper term: context sensitive.

Thanks for your example.
So, this is possible: https://codesandbox.io/s/test-zustand-forked-9b789

import create from "zustand";

const useStore = create(() => {
  const set = (...args: Parameters<typeof useStore.setState>) =>
    useStore.setState(...args);
  return {
    name: "",
    count: 1,
    setName: (newName: string) => {
      set((prev) => ({
        name: newName
      }));
    }
  };
});

This pattern doesn't allow us to add middleware. So, I'm not sure if we recommend it as a first class usage.

[dai-shi]

1. structural typing
2. context sensitive function

They are basically technical limitations, but could we somehow mitigate them?

[dai-shi]

@csr632 Check #174 . It would mitigate both issues with new middleware.