You see a new video from Jack in your feed, you click it. I will not be taking any questions. Thanks again for your almost eerily clear instruction, like you're injecting the information into my brain! 🙏
Long time listener first time caller. What we are battling with on the frontlines is proper error handling. You always kinda do the happy path in your videos. I wonder if you can sprinkle in some error handling here and there.
It's tough to do that and keep the videos succinct, but I get where you are coming from and I'll try to do more to add the error handling around the main subject of the video.
Thanks, clever that the cache is caching a Promise that use resolves. Good place where Typescript would make that clearer, suspect initial look at the code a person would assume it is holding json and not a Promise.
I believe it’s recommended to use useCallback to wrap the function that goes into use() which makes it pretty clean. Also I find it a bit weird that a promise (idsFetch) is hanging outside a component like that, maybe it was meant to be a function. WDYT?
Let me see if I get this right 🤔 If you put the promise into the component, it gets recreated every time the component renders. If you put it outside as a function, then again, calling that funtion recreates the promise. What I see here is that the promise is created once, and used as a reference inside the component. I imagine you can do some smart tricks with hooks inside the component, maybe use useCallback or useRef, to prevent recreating the promise, but this shows that not everything has to live inside a component, and it made quite much sense to me 😁
@@andreicojea The main problem is that this promise creates a side-effect when the module is executed. Modules should be free of side-effects for various reasons. The fetch request will execute even if the component is not rendered, as long as the module is imported somewhere. Think about how confusing it will be if you render the this component in different parts of the application. You're also preventing tree-shaking from taking place.
Thanks for the good content! It's worth calling out that React will never see updates to the data cache because it lives outside the React tree. I'm looking forward to trying out Preact signals, just rediscovered Preact after watching your vid on Fresh.
Isn't that already possible? I mean currently, if we throw a Promise, Suspense will wait for that promise to fulfill then try to render the component again. Isn't that the exact same thing?
Yeah, confused why we need this. We also literally just do !isFetching to wait for data before rendering. Why do we need this? Convenient yes but why…?
Really interesting concept the one with "use" hook and how React has matured from the traditional way of rendering data while pending.. Also the cachedUrls approach is really appealing to me!
By the time I finished watching the video, I still didn't really understand how to use use. - 1: Will it be used on client side or server side or both? - 2: If calling the api takes 10 seconds, during those 10 seconds the website will be blank (no content)? That means it will block the html rendering stream? - 3: How to handle errors and loading status?
Hi Jack, thank you for the great content about react and nextjs. I tried to code along with you, and receice the following error: Uncaught TypeError: use is not a function. What I'm doing wrong?
You have the wrong version of react and react-dom. As I recall I was working off a beta version at this time, but the current version of React 18 should have it.
@@jherr Thank you for your answer. I'm using "react": "^18.2.0", "react-dom": "^18.2.0". In the beta react documentation I could't see a use() hook. Are you sure, that this hook is alrady part of react 18?
@@jherr Why does it not jump over the await and execute the state change then come back to the await. Is it because the outer function is await? I really enjoy your stuff and the podcast. I think you should concentrate just on bringing along intermediate developers there is so much junior developer trainers out there repeating the same thing. I think you would be a great intermediate dev instructor. I think the intermediate dev is underserved. We all keep learning and I think you can use less code and diagram out more theory and concepts. Just a thought. Look forward to the NEXT.js update after tomorrow. cheers Jim
Hoy Jack, would you mind to share the tooling behind your YT videos? What workflow and editors are u using so you have a perfect sync between screen recording and face recording? Thank you!
I definitely need to do that. But the secret is that I synchronize on a clap like in the movies. Not that that's a secret. :) I use an Atomos Ninja V to capture my video. I use Screenflow to capture the screen and real audio. I use Izotope to fix the audio. I use Premiere to sync the audio with the green screen video. And then I import the greenscreen into Screenflow, edit, output both the recording and the green screen independently, then I stitch it all together in After Effects. Though I'm moving that flow to Premiere, and will use After Effect to manage scene by scene. (Most videos are three scenes; intro, code, outro.)
@@jherr Thank you ! And I forgot to mention - you sir, you are the absolute/ultimate source for React.js - finally somebody who covers advanced concepts of this FW - keep it going please. Thank you for your work and for the whole community I can say - your teaching skills are beyond expected! Thank you and sending many greetings from Prague, The Czech Republic
You can't actually await init() because that would require making the function an `async` function which would return a promise and `useEffect` won't work with functions that return a promise. The reason that I define a function within the function that I send to useEffect is so that I can make it async and use await within the interior function.
Thank you for explaining this instead of just making fun of it. I get it "use use," neat joke. But what's it for? This is actually very useful and it's a nice insight on how Server Components are coming along. It's very promising.
I am currently using redux to handle app state, api data, error and loading state. Do i actually need this? What is the advantage? Maybe starting a new project using async components will be faster and cleaner? Thank you if someone will answer my questions
Question: Why can't they name it as 'useAwait' instead of 'use'? Excerpt from the RFC: You can think of use as a React-only version of await. Just as await can only be used inside async functions, use can only be used inside React components and Hooks.
Does use hook take a functional variation? Something like const bla = use(() => fetch('/bla')......) This way? This should resolve that issue without additional function declaration.
Not as far as I know. But would it help though? Because you'd be creating a new function reference with each render. You could use it in combination with a `useCallback` to stabilize the function reference.
@@jherr I assumed it would work the same way as the function variation of useState hook which only runs once. So if this worked the same way, it'd make it little compact.
@@risechess7114 I don't have the bandwidth to walk you step by step through this. There is a Discord server associated with the channel if you want support from the community discord.gg/tZweCBc4 . Please read and follow the #rules before posting, in particular do no @ me directly. But I strongly recommend instead of doing that, take the time to drive this yourself, it will teach you a lot about debugging through issues like these.
I'm quite worried about the arrival of this new use hook on React: use is a pretty broad name to begin with. Is it going to be in charge of managing any asynchronous process, why not useAsync better? or Why not useFetch, useRequest or a more specific name if it is only for processing requests? . What will happen to current design patterns that use state handlers? The React team keeps changing the rules of the game, instead of focusing on improving / changing its render engine to finish that mental model of re-renders, that's why more hooks keep appearing instead of giving a definitive solution to the issue of re-rendering. What are your thoughts? I leave open the thread.
It seems it's not correct to say that when using `use` it does one render without the data then another render with the data. You only get one log after `use` which seem to indicate the function is interrupted, as with a `throw`, then it re-tries rendering when the promise has completed. Not gonna lie, I don't like the promise caching shenanigans for now.
That's something that's mentionned in the RFC: `use` will actually throw until the promise is resolved. So this means that you can really only have one use per function, and components called in them will not be called until the parent `use`s are fulfilled. I personally don't like this feature. React is trying to stay away from compiling javascript code, but it is now employing tricks like `throw` to manipulate the code path at the cost of performance
The new framework QWIK seems to have gotten around the whole hydration issue & calls itself a resumable framework. What are your thoughts on QWIK Jack?
I've had some issues with it. I keep hearing great things. Trying it out. Getting frustrated. Dropping it. And then hearing great things again. About the furthest I've gotten with it is putting it into a benchmark against Deno/Fresh, Bun/NextJS, Node/NextJS, etc. and it ran about as fast as Fresh, which is good.
It's actually something that is not possible to do in user land. The RFC for the new `use` is for something very minimal to unwrap promises which user land libraries will be able to leverage to make awesome things.
not gonna lie all these new hooks are too much when people are still struggling with the old ones (useEffect). My advice to people, write all your business logic in something like rxjs, use react to only display things or react to certain events
I want to learn REACT but this "OVER CODING" for small stuff sucks. What i expected is configurable components to build things. Instead all kinda store ...nonsense reducer patter. No micro rendering...it sucks. I have done crud api for my database in typescript in 2 days. I am waiting for dashboard in front end. I need cleaner code development. I am watching every video to seee anyone write cleaner simpler code. I will avoid typescript nonsense for Front end. Its pure stupidity. Most of the bugs can be caught with visual code. Sure few can get in but that is minimal. There is no need for static typing if visual code can catch them as you type. May be i hate typescript syntax. It can work if its java syntax. There is no readability with typescript. Its ok in server coding though. All types has to be in Types directory in separate file. everyone doing typescript coding for the sake of typescript. its forced coding. I want to reuse components. Not this react nonsense way. some incompetent people created react and poured money. I did x-datagrid with nextjs13 . it works. its only 30 line code. You write billion line code if you did what i did. Also no double calls to server or rendering. localhost:3000/api/person/1 same code work for order or any damn table. complex queries goes via localhost:3000/qapi/getsomething ( database view ) and queries on them. I did prisma then did pure sql Only reason i am watching react is mui x-datagrid does what i need and also learning react for the sake of future job but i am in research mode to find what is my best option for front end. want same for mobile app development.
You see a new video from Jack in your feed, you click it. I will not be taking any questions.
Thanks again for your almost eerily clear instruction, like you're injecting the information into my brain! 🙏
So glad you covered the fact that React Query and SWR still have a place in the world. Data Caching is still a thing.
Yea, also the fact that React Query has such good defaults can't be overlooked.
Also retrying, offline support, optimistic updates, etc etc
Long time listener first time caller. What we are battling with on the frontlines is proper error handling. You always kinda do the happy path in your videos. I wonder if you can sprinkle in some error handling here and there.
It's tough to do that and keep the videos succinct, but I get where you are coming from and I'll try to do more to add the error handling around the main subject of the video.
Great video! So hyped about the ergonomics of async server components. Hopefully the upcoming cache RFC addresses the concerns with cascading.
Sir, you are a fantastic tutor and very lucky to have a voice quality like a great teacher, 😊😊👍👍which is very important. Please continue 👏👏
I would like they named it "usePromise" or something like that
Actually I prefer use (like use(posts) ) but I haven't tried it yet so maybe i feel the same way when I got into coding
useFuture
Can't you always write a wrapper function for the "use" hook and name it "usePromise"?
@@dericksonloss also known as aliasing
Because they are planning to support types other than Promise like Context, streams etc.
Thanks, clever that the cache is caching a Promise that use resolves. Good place where Typescript would make that clearer, suspect initial look at the code a person would assume it is holding json and not a Promise.
Svelte is really setting the pace. Good to see React coming along.
Great video as always ❤️
Very informative video, looking forward to trying out 'use' in my projects.
I believe it’s recommended to use useCallback to wrap the function that goes into use() which makes it pretty clean.
Also I find it a bit weird that a promise (idsFetch) is hanging outside a component like that, maybe it was meant to be a function. WDYT?
Let me see if I get this right 🤔 If you put the promise into the component, it gets recreated every time the component renders. If you put it outside as a function, then again, calling that funtion recreates the promise. What I see here is that the promise is created once, and used as a reference inside the component. I imagine you can do some smart tricks with hooks inside the component, maybe use useCallback or useRef, to prevent recreating the promise, but this shows that not everything has to live inside a component, and it made quite much sense to me 😁
@@andreicojea The main problem is that this promise creates a side-effect when the module is executed. Modules should be free of side-effects for various reasons. The fetch request will execute even if the component is not rendered, as long as the module is imported somewhere. Think about how confusing it will be if you render the this component in different parts of the application. You're also preventing tree-shaking from taking place.
@@majorhumbert676 makes sense 🤔 I would love to see Jack Herrington releasing a follow-up video addressing these issues
4:50 ehh... I thought I would finally find out where I can shake your hand for all these React learning materials :D
I love watching your videos at night, they help me sleep! Do you think for Halloween you could be Goku? You seem like a big fan!
this ^
Yooooo this is legit exactly what I said in my comment on the RFC! "Seems like it could be at risk of becoming the next big foot-gun."
For the record, I love this take overall: this thing is really cool and opens up new possibilities, but it also creates high risk of these problems.
Thanks for the good content!
It's worth calling out that React will never see updates to the data cache because it lives outside the React tree.
I'm looking forward to trying out Preact signals, just rediscovered Preact after watching your vid on Fresh.
I'm not a computer guy. When this video popped up in my feed I thought I was having a stroke when I read the title. I'm glad it wasn't.
Isn't that already possible? I mean currently, if we throw a Promise, Suspense will wait for that promise to fulfill then try to render the component again. Isn't that the exact same thing?
Yeah, confused why we need this. We also literally just do !isFetching to wait for data before rendering. Why do we need this? Convenient yes but why…?
15:42 If I'm not wrong, I'll have to refetch the data on client side. Isn't it?
I've been waiting for this one
Thanks for the succinct explanation and the excellent to the point examples Jack!
At 10:50 you type $ then I think id to correct to {id}, is that an extension?
No, that's my fat fingering, and then removing it during editing. :)
I was like "Please don't reveal your position, please don't reveal your position".
Glad you're in "Tokyo".
Thank you Jack! Atleat now i can fully understand what it means and does!
The only video which explains use 👍
which vscode plugin counts console.log executions at 16:55?
That's Console Ninja, a new extension from the folks at Wallaby. This is an early preview that I got and I'm really enjoying it.
I think this extension is exciting at least as the new Use Hook 😱
Great content Jack! Keep it up.
Really interesting concept the one with "use" hook and how React has matured from the traditional way of rendering data while pending.. Also the cachedUrls approach is really appealing to me!
Hello @Jack what is the extension at 3.49 that show's the gray text ?
GitHub Copilot
The nope clip was great haha
By the time I finished watching the video, I still didn't really understand how to use use.
- 1: Will it be used on client side or server side or both?
- 2: If calling the api takes 10 seconds, during those 10 seconds the website will be blank (no content)? That means it will block the html rendering stream?
- 3: How to handle errors and loading status?
Hi Jack, thank you for the great content about react and nextjs. I tried to code along with you, and receice the following error: Uncaught TypeError: use is not a function. What I'm doing wrong?
You have the wrong version of react and react-dom. As I recall I was working off a beta version at this time, but the current version of React 18 should have it.
@@jherr Thank you for your answer. I'm using "react": "^18.2.0", "react-dom": "^18.2.0". In the beta react documentation I could't see a use() hook. Are you sure, that this hook is alrady part of react 18?
@@paneurhythmie Whatever NextJS 13 is pulling for React it's in there since NextsJS 13 in the app directory supports `use`.
Jack what stops the set Initialize state update in the use effect hook from running before promise.all completes?
The await. And if the await isn't there then the await that should be there. 🤣
@@jherr Why does it not jump over the await and execute the state change then come back to the await. Is it because the outer function is await?
I really enjoy your stuff and the podcast. I think you should concentrate just on bringing along intermediate developers there is so much junior developer trainers out there repeating the same thing. I think you would be a great intermediate dev instructor. I think the intermediate dev is underserved. We all keep learning and I think you can use less code and diagram out more theory and concepts. Just a thought. Look forward to the NEXT.js update after tomorrow.
cheers Jim
I like your videos! Would it be possible to do a series of videos on Next.js 13? Doing some projects with Next.js 13. Thank you
Thank you for the informative video.
Quick (and maybe unrelated) question: is it possible to use `useMemo` instead of implementing our own cache?
I've tried and it doesn't work for me. Conceptually I think it should work. Could be an issue on the experimental branch.
I'm too new to understand how it works, I'll save the video and watch it later
Great analysis and implementation!
nice video, while on the topic of prefetching maybe video for Qwik js
God forbid anyone plans a drinking game around the number of times the word "use" was said.
Hoy Jack, would you mind to share the tooling behind your YT videos? What workflow and editors are u using so you have a perfect sync between screen recording and face recording? Thank you!
I definitely need to do that. But the secret is that I synchronize on a clap like in the movies. Not that that's a secret. :) I use an Atomos Ninja V to capture my video. I use Screenflow to capture the screen and real audio. I use Izotope to fix the audio. I use Premiere to sync the audio with the green screen video. And then I import the greenscreen into Screenflow, edit, output both the recording and the green screen independently, then I stitch it all together in After Effects. Though I'm moving that flow to Premiere, and will use After Effect to manage scene by scene. (Most videos are three scenes; intro, code, outro.)
@@jherr Thank you ! And I forgot to mention - you sir, you are the absolute/ultimate source for React.js - finally somebody who covers advanced concepts of this FW - keep it going please. Thank you for your work and for the whole community I can say - your teaching skills are beyond expected! Thank you and sending many greetings from Prague, The Czech Republic
@@jaroslavhuss7813 Thanks! I really appreciate that!
Very helpful..thanks a lot.
at 19:12 how come you don't need to await init() ?
You can't actually await init() because that would require making the function an `async` function which would return a promise and `useEffect` won't work with functions that return a promise.
The reason that I define a function within the function that I send to useEffect is so that I can make it async and use await within the interior function.
@@jherr ahh ok thanks. For some reason I thought it a function was declared as async, it HAD to be awaited.
@@francis_n I can understand that, but no, you don't need to await an async function.
@@jherr Thanks, somehow I forgot that detail 👍🏾
Hey, could someone explain the meaning of footgun? Thanks
Any feature whose addition to a product results in the user shooting themselves in the foot.
Awesome video! What extension are you using for the inline console.log info at 17:00?
That's the new Console Ninja extension from Wallaby. They gave me a preview copy and it's amazing. Should be released soon.
what is this tool what make highlights on browser?
Hi Jack, why do you switch back to iTerm again? Is warp not good enough for you?
Fig has gotten to the point where I can't live without it.
What plugin do you use to have those predictions while you are writing the code? Btw great video 😁
GitHub Copilot.
Awesome video! But what extension do you use to show console.log on vs code directly? Looks cool!
That’s Console Ninja from the wallaby guys. I got a preview copy and I’m really digging it!
@@jherr Can't wait to try it myself. Please see if you can make a review on it.
How do you handle the error state for that Promise with this "use" hook?
I think you would need to catch it and then resolve it with the error encoded in the data and then check for the error in the component.
what are your thoughts about useEvent hook?
I thought it was a good idea.
Does it have any performance issue?
@@ayushtripathi4514 Don't think we would know until we have it available.
Thanks ❤️❤️❤️❤️
Definitely those libraries still very useful for auto refetching, caching et al. However this opens door to loads of possibilities
Thank you for explaining this instead of just making fun of it. I get it "use use," neat joke. But what's it for? This is actually very useful and it's a nice insight on how Server Components are coming along. It's very promising.
I am currently using redux to handle app state, api data, error and loading state. Do i actually need this? What is the advantage? Maybe starting a new project using async components will be faster and cleaner? Thank you if someone will answer my questions
No, you don't _need_ this.
What does first class support mean?
Support specifically designed for promises in the framework.
Great Video as usual!
Hey Jack, how do you get the inline virtual text for console log's?
That's console-ninja from the Wallaby folks. It's great!
Im so pumped for this new feature (hook or whatever people want to call this)
Hey sir, what is the name of that vs code plugin which autocompletes (predicts) the code before you are about to type it?
GitHub Copilot. Although it was pretty off base on some of its recommendations this time.
Question: Why can't they name it as 'useAwait' instead of 'use'?
Excerpt from the RFC:
You can think of use as a React-only version of await. Just as await can only be used inside async functions, use can only be used inside React components and Hooks.
It is a request for comment, so feel free to comment. :)
@Jack, would you be able to do some Vite Plugin content? writing some cool vite plugin to understand how bundlers work? this would be great
0:00 YES!
Would love an exemple of caching like this in a more professional cenario. Sometimes we can make do with just react
Does use hook take a functional variation? Something like const bla = use(() => fetch('/bla')......) This way? This should resolve that issue without additional function declaration.
Not as far as I know. But would it help though? Because you'd be creating a new function reference with each render. You could use it in combination with a `useCallback` to stabilize the function reference.
@@jherr I assumed it would work the same way as the function variation of useState hook which only runs once. So if this worked the same way, it'd make it little compact.
Like useState(() => console.log('yo')) only prints 'yo' once no matter how many time the component rerenders, I assumed this would work the same way.
@@Zenexis I get yah. But it's not quite the same thing as useState since it's just a listener on a mutable source that it doesn't control.
the start of a new react era? 😛
its telling me use is not a function ??!!! any recommendation
Check the React version.
@@jherr },
"dependencies": {
"react": "experimental",
"react-dom": "experimental"
},
@@risechess7114 I don't think that's required anymore. It should be there in 18.2 which I think is what NextJS 13 depends on.
@@jherr so your suggesting i change the depancancies to 18.2 and npm install and try it ...
@@risechess7114 I don't have the bandwidth to walk you step by step through this. There is a Discord server associated with the channel if you want support from the community discord.gg/tZweCBc4 . Please read and follow the #rules before posting, in particular do no @ me directly. But I strongly recommend instead of doing that, take the time to drive this yourself, it will teach you a lot about debugging through issues like these.
I'm quite worried about the arrival of this new use hook on React: use is a pretty broad name to begin with. Is it going to be in charge of managing any asynchronous process, why not useAsync better? or Why not useFetch, useRequest or a more specific name if it is only for processing requests? . What will happen to current design patterns that use state handlers? The React team keeps changing the rules of the game, instead of focusing on improving / changing its render engine to finish that mental model of re-renders, that's why more hooks keep appearing instead of giving a definitive solution to the issue of re-rendering.
What are your thoughts? I leave open the thread.
I like `useAwait` since that's exactly what you're replacing
But there are differences right? 🤔
Await "blocks" until it's ready. Where this is going to return null until it's resolved and then it's going to return the data from the promise.
Is it still an experimental feature?
Apparently not. It’s been promoted to just “use”
One day, Jack will find out about NeoVim, and will never go back... :D
So.. its Nuxt?
I really struggle to see which problem this solves. It just makes your code dirty by using async callbacks.
dumb question. what does RFC stands for?
Request For Comment
It seems it's not correct to say that when using `use` it does one render without the data then another render with the data. You only get one log after `use` which seem to indicate the function is interrupted, as with a `throw`, then it re-tries rendering when the promise has completed.
Not gonna lie, I don't like the promise caching shenanigans for now.
That's something that's mentionned in the RFC: `use` will actually throw until the promise is resolved. So this means that you can really only have one use per function, and components called in them will not be called until the parent `use`s are fulfilled.
I personally don't like this feature. React is trying to stay away from compiling javascript code, but it is now employing tricks like `throw` to manipulate the code path at the cost of performance
@@shadamethyst1258 I think you can have multiple `use`, but they will run as a waterfall.
font ?
JETBrains Mono
I'm a simple man. I see a Jack Herrington video, I like it first, and then I watch it!
Thank you!
@@jherr , Thank YOU for the valuable info in every video! Keep 'em coming
The new framework QWIK seems to have gotten around the whole hydration issue & calls itself a resumable framework. What are your thoughts on QWIK Jack?
I've had some issues with it. I keep hearing great things. Trying it out. Getting frustrated. Dropping it. And then hearing great things again. About the furthest I've gotten with it is putting it into a benchmark against Deno/Fresh, Bun/NextJS, Node/NextJS, etc. and it ran about as fast as Fresh, which is good.
@@NosherwanGhazanfar Solid Start is more interesting to me just because the familiarity level with Solid is great.
@@NosherwanGhazanfar I will say that I'm getting requests about Qwik on every video nowadays, so maybe I just need to do it. :)
@@jherr that would be a great help 🙏🏽
i am also trying to find time to learn more about it
Don't waste your time on such a frameworks, just use react-based framework, like Remix for the ultimate DX.
Feature creep imho. Now they are trying to do everything
It's actually something that is not possible to do in user land. The RFC for the new `use` is for something very minimal to unwrap promises which user land libraries will be able to leverage to make awesome things.
React is a foot gun
I don't disagree.
I see another half baked useEffect over there.
Gladly frameworks like Vue/Svelte allow you to have async components without weird `use` syntax...just using plain javascript with async/await.
_use_ is just a function call; it's not syntax. And Vue and Svelte are the languages/frameworks with special syntax, not React.
not gonna lie all these new hooks are too much when people are still struggling with the old ones (useEffect). My advice to people, write all your business logic in something like rxjs, use react to only display things or react to certain events
I don’t understand why useEffect confuses people so much. It literally could not get any simpler. I hear this all the time and it makes zero sense.
Still using Angular in the same way like I did 3 years ago, where none of this shit exists...
useAsync
React just gets more and more clumsy and less and less elegant.
I want to learn REACT but this "OVER CODING" for small stuff sucks. What i expected is configurable components to build things. Instead all kinda store ...nonsense reducer patter. No micro rendering...it sucks. I have done crud api for my database in typescript in 2 days. I am waiting for dashboard in front end. I need cleaner code development. I am watching every video to seee anyone write cleaner simpler code. I will avoid typescript nonsense for Front end. Its pure stupidity. Most of the bugs can be caught with visual code. Sure few can get in but that is minimal. There is no need for static typing if visual code can catch them as you type.
May be i hate typescript syntax. It can work if its java syntax. There is no readability with typescript. Its ok in server coding though.
All types has to be in Types directory in separate file. everyone doing typescript coding for the sake of typescript. its forced coding.
I want to reuse components. Not this react nonsense way. some incompetent people created react and poured money.
I did x-datagrid with nextjs13 . it works. its only 30 line code. You write billion line code if you did what i did. Also no double calls to server or rendering.
localhost:3000/api/person/1 same code work for order or any damn table. complex queries goes via localhost:3000/qapi/getsomething ( database view ) and queries on them.
I did prisma then did pure sql
Only reason i am watching react is mui x-datagrid does what i need and also learning react for the sake of future job but i am in research mode to find what is my best option for front end. want same for mobile app development.
this caching outside the rendering is horrible
i wasnt tired about useEffect but hey use() seems like an improvement tbh