Suggestion: drop uncurried support of create

[devanshj]

I've lost count of how many people have missed the extra parenthesis in create()(...) (and the wrong usage ie create(...) doesn't even get caught because it's allowed). I don't see how supporting the create(...) usage adds any value, it's just creating trouble for many people (including me). I know I've suggested this before but I want to make the suggestion official hence opening an issue.

[dai-shi]

Thanks for opening a suggestion. Let's wait others to comment. One note is as such a change is breaking, it will be only possible in v5.

That said, my personal comment would be a) create(...) is still very valid and natural syntax for JS users, and b) create()(...) simply doesn't look comfortable, so I prefer to use create(...) without middleware, and I'm not a big fan of middleware. They are mostly preference, and my mind could be changed on this.

(I understand there are many troubles, and wonder if there's any other way to mitigate it, like warning for the usage of create(...) only in TS. Otherwise, eslint-plugin-zustand would be one solution. Or, hm, we could attach api.middlwareIsUsed property and warn it.)

[devanshj]

There's also an option to support it in runtime but not include it in types (ie .d.ts won't include the uncurried overload).

[Gustav-Eikaas]

Maybe i'm misunderstanding but is this the two types of syntaxes we're discussing?

type Test = {
  name: string;
};

const curried = create<Test>()((set) => ({ name: "Yes" }));

const uncurried = create<Test>((set) => ({
  name: "string",
}));

Personally I prefer the uncurried one and find the curried one weird..
Callback initializers are pretty common in the world of JS

[dai-shi]

Maybe i'm misunderstanding but is this the two types of syntaxes we're discussing?

Yeah, in summary:

• In TypeScript, the curried one is required if you use middleware (not all of them, but with store mutation, but hard to know which).
• The curried one works for all cases, both in JavaScript and TypeScript
• In JavaScript, the uncurried one works for all cases.

[ollwenjones]

We use TS, and have used the uncurried version almost exclusively, and have not had any problems, I guess because we aren't using middleware that requires it. We tend to use type inference on factory function return types for different slices, with good results.

[charkour]

The idea of eslint-plugin-zustand would be great. I've been wanting to make one so we can add optional rules like always-use-selector when calling useStore in a React component.

[dai-shi]

Seems like eslint-plugin-zustand would be a viable solution.

[dbritto-dev]

There's a way to support uncurried version for TS as well with middlewares? I would like to have just one way to do both, with and without middlewares.

[ollwenjones]

@dbritto-dev we aren't currying, but its fine because we aren't using middle-wares. It seems like some middle-wares require it.

[dbritto-dev]

@dbritto-dev we aren't currying, but its fine because we aren't using middle-wares. It seems like some middle-wares require it.

@ollwenjones actually, I would like to have just one way to do both

[dai-shi]

#2137 (comment)

@devanshj I don't remember we discussed this before, but is there any possibility to avoid currying, if we introduce a new function like applyMiddleware(...), hopefully without changing createStore JS code, or may be just a little bit?

[dai-shi]

well, it's unlikely...

(For anyone curious, here's the original detailed post: #710 )

[devanshj]

I don't understand what's applyMiddleware(...) but regardless there's no way to avoid the currying.

[dai-shi]

Thanks for your comment. Never mind about applyMiddleware(...), which could be anything if it can avoid the currying.

Seems like eslint-plugin-zustand would be a viable solution. 👉 #1865 (reply in thread)

[dai-shi]

I would like to promote the use of zustand-slices with which works well with the uncurried version.

[dai-shi]

So, that makes me feel that dropping uncurried support is not a good idea.