@@iudexgundyr8635 yeah maybe when the performance issues of using context aren't an issue to you. We have 100s to 1000s of entities in redux currently, doing that in contexts wouldn't be a good idea imo.

@Iudex Gundyr I don't know where it's written that "developers" feel they have to edify their identity by being precious about their solutions. If you like your thing and they like theirs, and you both are getting the results you want out of it, yay. You're making baseless assumptions and being rude instead of carrying on a conversation. If he has information that would go against what you're talking about, that's a chance for you to learn. If you're correct and they're all terrible, this would be a chance to provide helpful information in a polite manner, so they can benefit from your experience and wisdom and the whole industry gets elevated. Being jerky doesn't make you cool or a better developer. It gives us all a bad name. It's not constructive. He lived his experience. He doesn't need you to pretend to be an authoritative source about what happened in his own life.

I'm dying for big project with Next13, react Query, Recoil, Jest for testing, performance monitoring that would be awesome

He already did a couple weeks ago

optimistic updates are simple in tanstack query, you can just setquerydata in your mutates onMutate callback, then invalidate the query in onSettled, make sure to hold the previous data in the mutate functions context before doing the setquerydata above, so if something goes wrong, you can roll it back with another setquerydata in the onError callback

On small size projects, what works good is to keep data in a static field of a class outside of the component, and get it by a function which refreshes it when needed

@@ylcsl4378 I use this method a lot when building backend with express but not so much on the frontend. But I suppose it would work the same way

@@royz_1 the advantage on frontend is that each time page opens again, the data is refreshes

Thank you for the support!

same doubt

I think yes because if it is server state you can use same key in any components it will automatically deduplicate network request into one and auto revalidate cache.

@@dellavita3463thanks for your reply, the problem is that this table has its own data(store) and they could be changed during the user session, for example if there is a pagination and the user changes the paginations of the first table, the other 3 tables should be at the first page.

What about infinite scrolling, caching, and RTK pulls all data when u don't even need everything to pull

@@syed.simanta820 what do you mean? For infinite scroll you manage data on the backend like a normal pagination 😅 pag1 pag2 etc... you just call the next page from the API when you reach the bottom scroll height. Caching is the main feature of RTK query, so I don't get the question. And RTK query don't pull everything when you don't need, you can just use Lazy query to trigger data when you want.

If it is typescript then it is to tell that this value is not falsy so treat this value without checking null or undefined or any falsy value.

@@webbeg4672 Thanks 👍🏻 Yes, this is typescript

I was looking for this answer Thanks WebBeg

Community moving to react query now

This was just a bug in my code as I used 0 as my start page instead of 1

Agree

@@michaskiba3710 I'm using it everyday, I've used next.js swr, and both are ok, but meh, u can't do something more and your project be that good and flexible. I like next.js 13 that it have all that swr/react-query jazz baked in on top of fetch api, so maybe that would be better approach.

but what did you use instead?

@@DenProstoDen Sorry I don't understand the question. What do you mean by "use instead"? Instead of what?

@@jasonwelsh417 you didn't use useEffect, right?

@DenProstoDen No I was saying I don't see the issue with using useEffect for data fetching

Not required as apollo client also does the essential caching which react query is providing

@@aseemanand1 what is beter ?

Appending ! to an optional value is a way of telling TypeScript: "Hey, I know this value is not undefined or null, don't treat it as optional". You usually add it when you are 100% sure something exists. It's called "non-null assertion operator". useParams() method returns "string | undefined" when destructured, so he basically skipped the null/undefined check.