lecture is good but sound echoes??

SQL is unironically my favorite language. It is such an incredibly intuitive way to work with structured data. Although most implementations do not easily allow for code re-use or composition of functions (although i extensively use views, ctes and custom functions)

so just abstraction

Why react won? Because Angular forced everyone to use Typescript. They singlehandedly popularised typescript and kicked their dev share towards ReactJS.

This was great, more to help us find our way in all these rapid changing environments!

Impeccably engaging, loved your content! <3

Still not sold. Remix/React Router just fits so much better with how I want software to work: builds on the platform, small API surface, simple to reason about, etc. The `<Image />` component does look sweet though, but I have already built such a thing several times before. Not having to, or not being able to, surely makes Next a better sell, but it's just too much overhead around it wrt deployments and the whole ecosystem.

Your signals and strategies help me make more profit in the market.

Animations are smoooth

I'm newbie but here is my thoughts: I'm really concerned about the web dev , I think modern web dev could be revamped to something much better, easier and more intuitive. React was a mistake sure it resolved many issues back in the day but maybe we need to move on to something has better DX. why we render - rerender UI explicitly while we can use some MVU pattern that automatically updates and manage state for us. i.e a game engine. maybe it's overkill and it has its trade off but I believe many devs would love it . I learned gamedev then went to webdev finished full stack course but I don't dare to call myself a full stack developer , I'm learning svelte but I've to know why we got there. community support is much open in react thus I've to learn it too but seeing that ugly code is painful.. copy pasting snippet for specific problem won't get me anywhere, breaking the code base to smaller chunks help and overtime I gradually learn and understand concepts but overtime when I don't code often I forget all the knowledge & some concepts easily and have to Google snippets. from other developers. While I believe svelte is much better in DX I think it has it suffer from the same issue but far less annoying. i.e svelte kit 5 syntax introduce something similar to react again. some concepts such as observable pattern are friendly for this problem without using state management system , when the query fetch from a remote server maybe some realtime protocol i.e signalIR (websocket ) aka streaming might be better option? Game engine eliminate these in frontend and come with additional tools like state machine and animation timeline out of the box simplifying the workflow if you want custom animation/ behaviour for the ui and Entity Component System for data _ props Again I'm amateur and probably things I said is completely nonsense BS.

Nice course but it’s expensive for me 🥲 make a monthly sub for us low income Spanish developers 😂

I’ve been in go world for a moment still doing next js daily but man I love go and coming to this I’m reminded how crazy our js world is.

ive been working on nextjs and react since nextjs was released (same with react) and yet none of my jobs ever used RQ. SO it cant have won.

Using ignore variable instead of an abort controller 😂

I like the basic description of what a React component is: a function of state that returns a view. That is brilliant and I wish I'd heard that some years ago. Took me a while to grasp how React will call your components multiple times to render things! Which gets me to how hooks are a mediocre solution that always like they were pushing what React is capable of perhaps a bit too hard.

I wonder how many hours went into video editing... The process... Animation of code, graphics, syncing everything with a voice over. I would like to see how you do it. Thumbs up 🎉

Not sure what else is on your content backlog, but would be interested in watching the stories of certain coding design patterns (Big Four, etc.)

7:55 so the reason we ended up with async await syntax is because chaining can make it hard to get state further down the chain.

This is such amazing content,you should be proud of what you do. My respects to you sir ❤

Where can i read more about the 5 O'Clock rule mentioned in the video, it sounds interesting

Wow that buzzer/phone example was a stellar analogy for promise/callback

React query is just a weak alternative for the tooling GraphQL developers have already. for REST APIs react query makes a lot of sense over manual processes.

Nice 🔥🔥

Love it!. This pretty much summed up my journey to react-query too. I started building my own, it got complicated. Then I switched to axios-hooks, which was pretty nice. But then I needed the same functionality for non-http calls. (fetching data from a c++ wrapper). React query doesn't care what's in your async function, so it was perfect. Plus it has a ton more features that often come in handy.

"The problem is React" NOOOOOOOOooooooooo!!!!!!1111111

Too expensive, especially for anyone not earning in dollars.

Beautifully explained 🙏

great video, still don't understand why i would use astro for my content heavy site

0:14 Good video overall, but I have no idea what you're talking about when you're making a "five o'clock rule" metaphore nonsense. Perhaps I'm not familiar with some trivia, but the description you give makes little sense, either. "The level of abstraction bubbles up".... wtf does that mean? Is it good or bad for an abstraction to "bubble up"? Does it mean more of it or less of it? And what does "bubbling up" have to do with "five o'clock"? As for the main "story" of react query, in my opinion you don't stress enough how caching is the main idea behind the popularity of react-query (and how react-query probably wasn't even the first to do it, but that doesn't matter, it's still the best). At the time, everyone was writing hooks for async requests and everyone was putting data in some client store using redux, flux stores and home-made alternatives. And none of them succeeded because the notion of "caching" (vs "storing") was the missing ingredient. The difference between "storing" and "caching" is subtle, but in short, with "caching" you're writing each component without ever thinking to check if the data exists or not. You just fetch it as if you don't care about duplicate requests. And the cache resolves that for you. That's the brilliant part. With the "storing" paradigm you had to check whether the data was available, and if it was, then you didn't initiate a fetch. Such orchestration was a great pain. And this is how the notion of "caching" basically killed (solved) all the "state management" problems and experiments of the time.

6:49 some variations of the quote: There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery -- Mathias Verraes there's two hard problems in computer science: we only have one joke and it's not funny. -- Phillip Scott Bowden There are so many variations on the “there are only two hard problems in computer programming...” joke that I’m starting to suspect that programming isn’t actually very easy. -- Nat Pryce

My takeaway is that "imperative" and "declarative" are relative concepts like "new" and "old" but instead of the timeline the comparison lies in the level of abstraction. Any declarative code abstracts away some imperative code. However, the imperative code itself (unless you're writing machine code) will be declarative to an extent as it uses abstractions over lower-level concepts and computer commands. Hence, the same code is both declarative and imperative depending on the particular abstraction you're discussing. (e.x. the JSX definition for a Btn component may be treated as imperative code when compared to this component's actual use, but there's no denying that JSX is itself declarative as it abstracts away a lot of under-the-hood code)

"whah exactly do those words mean" dude you sounded just like main character in 7th Guest for a second there, gave me flashbacks.

nextjs is waaayyy too clunky to me, jQuery was way more easy to learn and understand, nextjs you find yourself looking at your own code like what is this why am i feeling like I'm missing something, not in jquerry

Great video, RC is one of my 'go-to' tools on every project i've

best and deeep explanation we need more from you sir and fullstack project tutorial will be a breeze to the fire

Every people in company watch this video. It's very perfect information

as a person who tries different approaches in pet-projects, I find React Query and Reatom best in how the handle data, although Reatom is a bit strange at first glance and RQ is a bit easier. Reatom makes you actually write code for your need, really clean approach, RQ in that sense may be a bit clumsy you need to know your settings Thanks for the video

Waiting for the history of Svelte 😆

6:28 wtf was that?

and react compiler is here

Lol web dev reinventing the wheel and started using static typed language)

This makes me appreciate React Query even more

React is so terrible in 2024

I'am using redux-requests lib and i'm so happy to manage my CRUD operations.

Why did you remove the older videos from the channel? Please bring them back.

I love React Query. It's like a developer-friendly RxJS for the most common use case. Next time RxJS gets more popular, devs will say, "this kinda reminds me of React Query"

Really nice video. Can please tell us which tool used for animation ?

Thank you for using the analogy with math, the origin of everything (why we need to learn a concept from scratch when there is transfer learning (bijection)).

I already bought old react query course, Do i get free updated the course? or must buy a new one?

Was using SWR as it's a much simpler and approachable library, but the design is inconsistent which makes mutations painful. The mutator in SWR only modifies cache data; it doesn't include your network call. This mean your errors in mutation network requests are segregated from SWR. This is in contrast to fetching in SWR where SWR _does_ bundle the fetcher in the SWR call, so SWR could process this error. The amount of error handling doubles as the design decision of including/excluding the network request is inconsistent. It becomes quite difficult in SWR because you may make other network requests independent of SWR that are not mutations or SWR fetches, so you need to figure out if these are related to SWR or not _and_ if SWR would handle them or not. For example, if you have an SWR handler for fetcher errors but you also have a handler for all network request failures, the error may be reported to the end user twice. But you can't simply remove your network request error handling as then you'd lose handling of mutation errors which SWR won't catch or network errors unrelated to SWR. Unless you write some convoluted state machine for processing errors, you'd need to handle each mutation network call and SWR-unrelated network call explicitly while ignoring errors on fetcher network calls if you want SWR to handle those. In TQ, an error in either a mutation network step or a query's network step triggers TQ's `onError` so I can process the error there and it immediately removes all of this thinking.