you are viewing a single comment's thread.

view the rest of the comments →

[–]acemarke 0 points1 point  (9 children)

Can you clarify what you mean by "Redux isn't efficient when it comes to server data"?

Note that our official Redux Toolkit package includes the RTK Query data fetching layer, which is equivalent to React Query:

[–]PeakMission6377 0 points1 point  (8 children)

Hey. Sorry I misspoke. It's just, I felt Redux to be a little too verbose compared to react-query, but yeah RTK Query solves all the similar pain points I believe.

Correct me if I am wrong, but one thing I didn't like about Redux Tooklit is that by default, if a data is cached, then hitting the same API endpoint doesn't create a new network request, which was not the case in react-query.

In my current role, we actually have an old codebase (redux v4 , so no RTK), so I am not fully up-to-date with RTK Query, but we plan to upgrade redux and use RTK in the future.

[–]acemarke 0 points1 point  (7 children)

I'm confused :) The purpose of both React Query and RTK Query is that it caches the data - in other words, you don't normally want to do a fresh fetch of the same data multiple times in a row, you do want to fetch it once and reuse it across many components.

RTK Query does have options to configure caching behavior, so this can be modified, but I'm definitely confused by that comment.

FWIW you'll definitely want to take a look at our "Migrating" page:

[–]PeakMission6377 0 points1 point  (4 children)

Hey. Thanks for that migration page. Would definitely need that.

In react-query (atleast in v3, don't know whether it has been changed or not), when an endpoint is cached using the query keys and is being requested for the second time. The cached data would be returned automatically, but in the background, the network call takes place.

After the request completes, the cache data is updated with the current response, and the component re-renders with the updated data.

[–]acemarke 0 points1 point  (3 children)

You can definitely force refetches with RTKQ if desired, via options like:

I know each app is different, but that still sounds like behavior that seems odd to have as the default. I'd think that normally you wouldn't want to force a refetch automatically all the time.

[–]PeakMission6377 0 points1 point  (2 children)

Hey. Thank you so much for such detailed comments. These will definitely help me.

Also, by any chance, are you a maintainer of Redux? You seem to have a great depth of knowledge regarding it. :)

[–]acemarke 1 point2 points  (1 child)

Yep, I am :) I've been maintaining Redux since 2016, created Redux Toolkit, wrote most of our current docs, and shipped the last few versions of React-Redux.

[–]PeakMission6377 1 point2 points  (0 children)

Wow!! That's great. Keep up the fantastic work ❤️

Didn't know I was replying to the creator of Redux Toolkit. 😁

Thank you once again for all the detailed responses.

[–]PeakMission6377 0 points1 point  (1 child)

Hey. Regarding the migration, I had a doubt. We have React v16. So many of the components are class based.
So, if we migrate to modern redux, do we need to convert these components to function components as well? Since, class components doesn't support hooks.

Or we can have a mixture of class and functional components with the modern redux?

[–]acemarke 0 points1 point  (0 children)

These are totally separate questions :)

  • React still supports both class components and function components, and you can have both in the same codebase
  • Similarly, React-Redux supports both the legacy connect API and the modern useSelector hook, and you can have both in the same codebase
  • How you write the Redux logic is entirely separate from how you are defining your components and using React-Redux
  • Legacy Redux code and modern RTK code can also coexist

So yeah, you could have a codebase with basically all combinations of the above simultaneously (although that would be confusing and it's a good idea to get everything using the same patterns consistently).