kirill-konshin
Repos
84
Followers
108
Following
1

Events

Don't receive a props returned by getInitialProps

You should return ‘{props:{…}}’

Created at 19 hours ago
Don't receive a props returned by getInitialProps

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?

Created at 1 day ago
Don't receive a props returned by getInitialProps

Closing, no sandbox. Please provide codesandbox with reproducible scenario.

Created at 1 day ago
Hydration fix

Looks very good. I'm in favor of renaming the page props from initialStateABC to reduxActionsABC 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.

Created at 1 week ago

Update packages/wrapper/src/index.tsx

Co-authored-by: bjoluc mail@bjoluc.de

Created at 1 week ago

Apply suggestions from code review

Co-authored-by: bjoluc mail@bjoluc.de

Created at 1 week ago
Usage with Next.js 13?

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.

Created at 1 week ago
NextJs 13 using app directory with 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.

Created at 1 week ago
Hydration fix

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.

Created at 1 week ago
Hydration fix

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.

Created at 1 week ago
Hydration fix

Few more considerations regarding useHydration vs withHydration:

  1. Hook is more modern, but requires fixing of selectors (state => state?.foo?.bar), which is simple, but consumers will have to do it as part of migration
  2. HOC is older style, and most of libraries these days are abandoning it, but HOC is a bulletproof solution to prevent render of incomplete selectors
  3. BUT in general selectors should always be safe because: a. there's no guarantee when portions of state will arrive, and b. same selectors may be used on the particular page which dispatches hydration and elsewhere in the app, and HOC will not protect against this

So 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.

Created at 1 week ago
Get the initial state in useSelector instead of the dipatched store via getServerSideProps

Describe the bug

I'm using Electron with Next js with Nextron .

  • I dispatch actions from the server in getServerSideProps
  • the states is stored in the store
  • but when I use them via useSelector I got the initial state instead of the dispatched one

To Reproduce

https://github.com/tiavina-mika/noteo-desktop/tree/features/nextjs

Steps to reproduce the behavior:

  1. Clone or download the repository
  2. yarn install or npm install
  3. yarn dev or npm run dev
  4. See the console

## Expected behavior

Should have the dispatched state via getServerSide props

## Screenshots

![image](https://user-images.githubusercontent.com/42656064/171989213-d4ccc802-c87a-4453-8228-a5cc5183cbb2.png)

## Desktop (please complete the following information):

- OS: Windows 10
- Browser Chromium [for electron]
- Version [e.g. 6]


                                    
Created at 1 week ago