Anti-pattern or not? Using state managers with App directory in Next.js 14.
Unanswered
nyxz posted this in #help-forum
nyxzOP
Coming from plain React world I'm used to having a state manager in the application (like RTK https://redux-toolkit.js.org/ for instance).
With the server actions and the way we load data from external sources and manages state invalidation in the pages it feels that I should be passing data down from the root component to sub-components in the tree because I don't want to have multiple state managers. Would you agree that having RTK on the side in a app directory page would be considered an anti-pattern?
With the server actions and the way we load data from external sources and manages state invalidation in the pages it feels that I should be passing data down from the root component to sub-components in the tree because I don't want to have multiple state managers. Would you agree that having RTK on the side in a app directory page would be considered an anti-pattern?
3 Replies
@nyxz Coming from plain React world I'm used to having a state manager in the application (like RTK https://redux-toolkit.js.org/ for instance).
With the server actions and the way we load data from external sources and manages state invalidation in the pages it feels that I should be passing data down from the root component to sub-components in the tree because I don't want to have multiple state managers. Would you agree that having RTK on the side in a app directory page would be considered an anti-pattern?
It depends on what app you are building. I think its good to use RTK/RQ/swc when building a dashboard/stock or any other client side fetching heavy app. And we can also use server action with react-query or swc for mutation (not sure if it is possible with RTK)
nyxzOP
Oh, I didn't know that react-query can do that, thanks! The approach with
HydrationBoundary looks pretty neat.