You should return ‘{props:{…}}’
Hi, i just updated my next-redux-wrapper and change all my old "getInitialProps = (ctx)" to "getInitialProps = wrapper.getInitialPageProps(store => (ctx)"
However, it seems that i didn't get the props returned by the getInitialProps to use on my component client-side. I try to hardcode the returned value and they just didn't appear on my UI component. is there something i do wrong?
Closing, no sandbox. Please provide codesandbox with reproducible scenario.
Looks very good. I'm in favor of renaming the page props from
initialStateABC
toreduxActionsABC
since it's no initial state but actions.
Done.
I wonder how we didn't consider replaying actions before 😅
Better late than never... HYDRATE
was also fine. I started to brainstorm how to implement wrapper for new app
directory, and got an idea to push updates in a granular way, because there any server component can push bits of new state. But turned out Redux can't be used on server, at least for now. Nevertheless, the idea was quite useful.
Update packages/wrapper/src/index.tsx
Co-authored-by: bjoluc mail@bjoluc.de
Apply suggestions from code review
Co-authored-by: bjoluc mail@bjoluc.de
So far there is no clear way to use Redux with Server Components...
First of all, components that use Redux needs a Provider
up in the tree in order to work, and Provider
is using Context
, which is not available on server (yet?).
With that said, I suggest to keep Redux as client component ("use client"
), and keep server-side state outside of Redux.
So far there is no clear way to use Redux with Server Components...
First of all, components that use Redux needs a Provider
up in the tree in order to work, and Provider
is using Context
, which is not available on server (yet?).
With that said, I suggest to keep Redux as client component, and keep server-side state outside of Redux.
I just had a breakthrough moment. I have ditched HYDRATE
action, and started to just replay all the actions that happened on server. No more issues with tricky hydration, no more server/client state separation problems. I have deleted a few sections of readme, it's now much simpler.
Proper GIAP+GSP/GSSP
Proper GIAP+GSP/GSSP
So I am considering to just return loading status without loadingSelector, as this would enforce better coding practices.
Yup, fully on board with that. Folks should either use optional chaining in a selector, or let the store ensure the selected path is available at any time. Let's keep things simple on our end; the Readme is bloated enough :D
Readme have been shortened a bit, and I will cut it down even more ;) it's a direct consequence of tricky Next.js props management. And it will be even worse if I will find a way to make wrapper to work with Server Components and new app
folder.
Few more considerations regarding useHydration
vs withHydration
:
state => state?.foo?.bar
), which is simple, but consumers will have to do it as part of migrationSo I am considering to just return loading
status without loadingSelector
, as this would enforce better coding practices.
Honestly, I have a question to authors of useSelector
, because it can't handle useSelector(null)
, unlike, say, SWR, where useSWR(condition ? '/api/foo' : null)
is a perfectly legit pattern.
I'm using Electron with Next js with Nextron .
https://github.com/tiavina-mika/noteo-desktop/tree/features/nextjs
Steps to reproduce the behavior:
yarn install
or npm install
yarn dev
or npm run dev
## Expected behavior
Should have the dispatched state via getServerSide props
## Screenshots

## Desktop (please complete the following information):
- OS: Windows 10
- Browser Chromium [for electron]
- Version [e.g. 6]