docs(typescript): clean up bounded useStore recipe
#1581
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 2c46051:
|
| function useBearStore(): BearState | ||
| function useBearStore<T>(selector: (state: BearState) => T, equals?: (a: T, b: T) => boolean): T | ||
| function useBearStore<T>(selector?: (state: BearState) => T, equals?: (a: T, b: T) => boolean) { | ||
| return useStore(bearStore, selector!, equals) |
There was a problem hiding this comment.
We need the ! after selector because our types are incorrect, they don't allow writing useStore({} as StoreApi<unknown>, undefined, () => true). I had told @dai-shi about this in #725 but he said that passing undefined is an incorrect usage. I personally think in most cases types should remain true to the implementation otherwise problems like this pop up.
I mean it's not a big deal but still in case if you change your mind and want to make our types more correct then let me know I'll open a PR (we just need to add a ? after selector in out useStore type).
There was a problem hiding this comment.
Yes, I still think this is good. (But, I may change my mind in the future. In that case, I think I know what to do.)
|
Ah yes prettier made my code uglier yet again :P |
(as the react store is already a bounded useStore hook)
There was a problem hiding this comment.
LGTM.
Apart from this PR, I still think not everybody has to read this guide fully. While sections may work, I wonder if we can split the guide into two parts: one for beginners, and the other for exports. The border would be difficult to define though. Or, maybe this guide is for latter, and we need something new for the former.
Oh that's absolutely true. The first two sections ie "Basic usage" and "Using middlewares" is sufficient to address most of the TypeScript usage. So perhaps a split can be done there, a "TypeScript usage" page that has these two sections and then a "TypeScript advanced usage" that has remaining ones. Or something like that, pages could be named differently too, just giving an overall idea. |
I personally like that. Let's see how others think. |
I agree with this approach |
|
Thanks for cleaning up the docs. The idea of splitting the typescript docs into a basic and an advanced part sounds good to me! |
Supercedes #1565.
The recipe added in #1565 is unnecessarily wordy beyond measure. That's not to blame the author (or the maintainers) as they might not be aware of how the TypeScript guide is supposed to be. I just want to clarify my intention of the TypeScript guide as the original author: A succint to-the-point document that shows you how to deal with TypeScript, period. (This ignores the extra collapsed sections of course, which is precisely why they are collapsed.)
Which means it's not there to teach you how to use zustand patterns or anything. If you look at every recipe, it's literally just a snippet to show you the typings. So when the user comes to the "slices pattern" recipe for example, it is assumed they know what "slices pattern" already is, hence we don't teach slices pattern here but instead link at a detailed explanation at the end if they aren't familiar with it.
This is the mistake that #1565 does, it's way too tutorialy (has "steps" and is worded like so), has too broad scope (talks about testing and stuff), repetitive in that it shows how to use middlewares, mentions the extra parenthesis etc (those are not needed here).
So my suggested change is in this PR. If we want to "teach" this bounded
useStorepattern (well it's not much of a pattern, it's just partial application) then it can be done in the readme or a seperate guide and then link it at the end as we do for slices pattern recipe.Just my two cents, please feel free to close this PR if you don't like it.