Reducers Q&A

[00:00:00]
>> Cool, all right, so we had one question from the chat. And then one question from the room. So the question in the chat was can I repeat what the main benefit of switching to use reducer. I'm taking that over use state. To be clear, if you're going to pass use state down and you can deal with what you're getting in the function callback.

[00:00:18]
And not wrapping additional functions in that top level that you need to have the memory reference to. Use state is just a abstraction over use reducer they are functionally the same, which means it comes down to a matter of taste, right? With use state you have just that one item that you set in the very beginning.

[00:00:39]
Could you set it to an object with multiple values? You could. At that point are you almost just reimplementing use reducer with your state which is on top of use reducer? You are also doing that, right? But in terms of technically and functionally, it's purely a matter of taste, right?

[00:00:55]
That said items or whatever, that was static, right? And the same thing, dispatch is also the same. I just like having one dispatch where I could have a whole bunch of things that are derived from that. I personally, and I can pull that function out and unit test it super easily.

[00:01:12]
I personally like it. And I can just say, hey, this thing happened. Here's all the information you need and cast it away instead of doing it by UI layer. That is not a performance hack. That is simply I think the pattern is really good and then also dispatched and I don't even, it's just one function.

[00:01:31]
It's always the same. It's the simplicity of it. Causes me to make better performance decisions and I don't feel like I'm giving anything up. So I like it, but I don't feel like if you were no, I really wanna use use state, I'm okay, that's fine. Alex, had a question.

[00:01:51]
>> Yeah, I noticed in the flame graph. The leaf most items such as the most components do not contain, the pure HTML elements there for renters. Can you address that?
>> Yep, so yeah, the question was, basically we only see components in here. Right, and that's kind of a subtle nuance to one of the kind of graphs that we saw in the very beginning.

[00:02:16]
Is the way that it works is like, components get rendered, right? Because they have logic in them. And so React goes through each one, renders them. Runs through the logic, gets the output, and keeps moving along. Either of you ever take JSX and look at the compiled code?

[00:02:37]
It's like, you know, JSX.createElement, so on and so forth. It's like, we all tried in like 20 14 for a hot minute to be like, I'm not using this JSX thing. I'm gonna write it in regular JavaScript. And we all did that for a good day, right? Or maybe two if we were really stubborn.

[00:02:56]
So you can see what it looks like. But those aren't actually functions. They're just strings at that point. And so like for React that is a dead end. Assuming it does not continue going down those they don't. If you think about these with that children, right? They don't really have any logic in them, they have children which belong to the parent component, right?

[00:03:14]
That same thing that we saw with the pulling the content up is true but they also are not functions. So React is not working through them in the rendering cycle. That is the end of the line of each one of those traits. So as soon as you get to the final component that is only HTML elements.

[00:03:29]
It is game over but they are not rendered per se. They're not going through this entire process of comparing a button with X, Y, and Z things. It's just gonna turn into the same effective data structure the same ASC every time.