Making setState() instant

[@sirawichvoungchuy3128]

OMG, this guy clearly explained the blackbox part of state in React to me. I can't wait for the next video!

[@johnc0de]

> Tries to fix react > Automatically starts to become SolidJS

[@joshuathomasbird]

i mean even preact has signals...

[@igrb]

very very interesting exploration, learned so much, nice

[@ostadomid3355]

Thank you for detailed explanation.💯

[@andreilucasgoncalves1416]

Great video, I was prepared to explain here why React team decided to keep that way, but you will in the next video Unfortunately in React with hooks we have to use ref frequently to deal with stale state in useEffect and useMemo

[@zzzuq]

Wow, this is soo useful, thanks

[@rcnhsuailsnyfiue2]

Another great video, thank you! 👏 You’re a really good teacher and explain the hidden complexities of React in a simple and clear way.

[@minyoungna6642]

Ahhhh I love getters and setters for making the code more imperative!!

[@Thassalocracy]

Great explanation about useState and useRef. In essence, it all boils down to having a very good understanding of the fundamentals of JS as a PL. This is what I don't like about frameworks sometimes - they abstract the functionality so much that we don't know why the code has to be written the way it is.

[@brabbit2325]

That's clever, great video! Hoping for more

[@orterves]

Why not have the setState call return the updated value? Make the code more functional, avoid the need to .current or the getter function

[@excalibur2506]

What if you want to getState multiple times at multiple places

[@orterves]

@excalibur2506 I don't understand the question. The state won't change if you don't call setState, use whatever value was last returned as much as you want? I think if someone was going to mess with reacts rendering expectations like this, a functional approach would probably be better to prevent accidentally trying to get before set

[@excalibur2506]

@@orterves You call setState within some function, but you want to access it's returned value outside the function. You will end up creating another ref in that case. So why bother when you can getState

[@orterves]

@excalibur2506 my point is I think developers should think very hard about whether they really want to do that in React. Mutable state that breaks the expectations of uni-directional data flow needs to be carefully implemented

[@oliversaxon8656]

@@orterveschill man. This video was just an experiment

[@figloalds]

Ah yes, a lot of laps to do what Svelte does out of the box

[@vpetryniak]

Or you can just use SolidJS

[@unicodefox]

@preact/signals ;)

[@nafg613]

Possible improvement: instead of two functions, return one function that gets if no parameters and sets if passed a value

[@TheJobCompany]

I prefer having two separate functions because it is generally simpler to explain and understand when reading the codebase for the first time. However, when implementing a polymorphic getter and setter function, there is a potential issue - you can accidentally make it impossible to set the value to undefined or null. This could happen because passing an undefined or null value as the parameter is treated the same as if no parameter had been passed. To be fully correct, you would have to use a unique Symbol or a unique sentinel object reference as the default parameter value to be able to distinguish those cases.

[@nafg613]

@@TheJobCompany True. We don't have that issue in Scala ;)

[@injSrc]

​@@TheJobCompany try checking out arguments array in function. It solves the problem

[@rodrigonovais9624]

1:20 Not sure if anyone remembers it but "async" does existed before the keyword async exists We have callbacks, yields, generators...

[@injSrc]

To be honest, I was never really bothered for not being able use the updated value

[@aro_matt]

So you say that rerender of the parent rerenders the children? Is that really true statement? In the scenario I have: Function Example(){ return ( )} Will internal state updates in parent cause rerenders of the child?

[@guillaumebrunerie]

Yes

[@adnanearef2959]

So use basically invented a `useStatefulRef` hook.

[@nuvotion-live]

All the asynchronous stuff has made my option of react really sour over time. It seems totally unnecessary

[@nuvotion-live]

It’s also very inefficient out to the box. Memorizing adds its own technical and mental complexity, and the compiler absolutely does not even begin to solve this. I decided to rewrite my app using ImGui after 5 YEARS of using React. The performance and complexity is night and day 😮‍💨

[@kratos_respawned]

I guess we can just use flushSync

[@Joshua-dc4un]

If you need the value immediately at the point where you called setState, you already have the value that you passed to setState, so use that 🤦🏽. If you need that value immediately somewhere else, then you have a wrong application architecture or maybe React isn't the right choice for your software.

[@wixoooooo]

Hey, great video, man! I just wanted to note something: there is no such thing in JavaScript as 'pass by value' and 'pass by reference.' That's not how JavaScript works. Pass by value and pass by reference works in languages like c/c++ not JS.

[@sohamkarandikar6726]

Could you explain a bit more as to what you mean by javascript has no pass by value/reference?

[@zayne-sarutobi]

Are you sure you know what the heck you're saying?

[@wixoooooo]

@@zayne-sarutobi yep my friend. ;)

[@wixoooooo]

​@@sohamkarandikar6726 It's really hard to explain this in a comment because the answer is broad. To fully understand it, you should read the ECMAScript specification and one of the host environment specifications, such as V8. However, I'll give a small example to help you start your investigation, which you can also test on your own. Let's say you create the following variables: let a = "xyz"; let b = "xyz"; let c = "xyz"; In this case, you are not storing three separate values in memory. Instead, you're storing a single value, "xyz", and all three variables a, b, and c reference the same location in memory. So, there are not three "xyz" values in memory, but only one. For a better test, you could create a large string: let a = "...10 MB long string"; let b = "...10 MB long string"; let c = "...10 MB long string"; In this case (if all variables are identical), you won't occupy 30MB of memory but only 10MB. All three variables will reference the same value in memory. So technically you are passing REFERENCE VALUE to a function, not a VALUE. Under the hood, V8 might optimize it like this: V8_variable_long_string = "...10 MB long string"; let a = V8_variable_long_string; let b = V8_variable_long_string; let c = V8_variable_long_string; As you can see, all the variables share the same reference. Although when looking at your code, you might think you have created three independent variables with independent values. So, in any case, you are passing references or references value to a function, not actual values. It doesn't matter if you're passing a primitive value, an object, an array, or even another function-what gets passed is the reference to the value or reference to expression etc.