Anton Zinovyev
Anton Zinovyev
What i'm thinking now - we can offer type extension for SSR users, and basing on that extension all types for SSR-sensitive hooks will switch to SSR-compatibility mode. Guess it...
Well that was the point of plugin We have to enforce extensions otherwise esm won't work.
Nah, it is not a problem to set state - problem is in typings of hooks return. Now it works basing off parameters value, with this hook i dont yen...
Nope Just enforce it on linter level.
Just as an idea: what SSR users think about the solution i18n uses: https://react.i18next.com/latest/typescript So basically it will require to redeclare some types, along with such hook (that i'm planning...
_maybe_ we have to consider finally switch to `"type": "module"`. As for me we finally migrated all our production services to native esm.
so here's the plan. 1. process current PR's 2. migrate to new hooks testing library (`@testing-library/react-hooks` -> `@testing-library/react`) 3. migrate to type: module 4. migrate from storybook to docosurus (supposedly,...
Thre is basically no difference, afaik, since i don believe current `useStorageValue` has SSR-compliant code eliminated
This pr brings such context value to switch all hooks it one move
Sadly had a few time lately, therefore havent tried that hook. I'll try to cut some time this week to have a closer look.