DEV Community: Felipe Gustavo

Why Zustand suceed in the React state management war?

Felipe Gustavo — Wed, 22 Jan 2025 17:27:39 +0000

Zustand reached 49 thousand stars on github last week, which got everybody impressed.

In the last years we saw a change in the state management field, especially in React. The older champion, redux, is slowly becoming a legacy only library, not being so popular like it was.

Redux era

Redux had the tragedy of being in the right place at the right time, but maybe, not in the best shape. It was the only library that remained from the Flux War, and became the default library on React, especially in the class-based applications era.

Their success was good and evil for them. Because more and more, applications that didn’t need a library like redux were using it. And its rawness made everybody stick to huge boilerplates to structure their states.

I said the wrong shape, because I think that, if redux-toolkit was the version people used a lot in the past, their views on redux would be different today. Being more positive, than it is.

And here we come to Zustand.

The new champion

Zustand is maintained by Poimandres and their lead maintainer is Daishi Kato. The interesting part of it is that they have not just one, but three state management solutions: Zustand, Jotai and Valtio.

Valtio is the one with least success of the three, but Jotai and Zustand, are, of course, the two bigger ones of the new generation, even though they are VERY different from one another.

Jotai is an atom-based library, with very design inspiration on reactivity. We have a series on reactivity in react, by the way. With a simple and minimalist API, it’s today, the best atom-based tool for React.

But being an atom-based library is not easy. As we know, people still struggle with reactivity and the atom model can be pretty strange for the users that are used to using bigger data structures to handle their data.

That makes the adoption to Jotai harder, and here is the point where Zustand shines the most.

Think that, here in the future, we could look to the past and create a better version of something? This is the sensation I had looking at Zustand. Seems like a new version of redux, with a refined and minimalist API, joining things that were splitted (like state and actions) and delivering good typescript support and a powerful middleware system.

These two aspects are very important to me. When you choose a state solution to your application, you may need to extend some functionalities. Redux had a good middleware system, but more complex. Zustand got it right.

Another important difference is the multi-store approach, instead of gigantic states, on Redux. This way you avoid the creation of big reducer combinations and can organize better your architecture, splitting the real global states from page/feature local states, that benefits of being outside of React, without being in a huge blob of redux.

So this makes the success of Zustand not a surprise for me. For the user, it follows the natural React way of thinking, and at the same time seems like a cleaner option if you don’t want to fall in the hell of Contexts (that are so verbose and confused such as old redux was, even its adopters say the opposite).

The problem with usePrevious and similar time oriented hooks

Felipe Gustavo — Mon, 16 Dec 2024 18:47:36 +0000

Theo did a video this week about unintuitive behaviors of React hooks, exploring especially the idea of a hook called usePrevious, to keep the value version of the last re-render, before the current one. A way of doing some logic with the old and new state.

If you want to see ideas of how to implement it, please check the video, in this post the idea is to explore the conceptual aspect of having a hook like usePrevious.

Reactive expressions

As you can see, we don’t have a primitive hook like this in React. Before hooks, in the class-based era, we had a lifecycle method called componentDidUpdate where we got all the previous state and props as parameters, why didn't they keep this behavior with hooks?

It can be a little repetitive if you are reading this series of posts, but we need to talk about the paradigm shift, in this case.

With classes, when some state updates, you don’t have an automatic way of recalculating the derived values. If you are using some specific props and states to calculate some new value, you need to verify by yourself if some of them have changed.

This way, the solution is to have a callback that is called in all updates, and send to the user the previous values. The app code checks the differences and updates the calculated state with the new result. This is the directness of class-based components, you have complete control of the flow of data, and need to manually control the calculations.

Here we come to reactivity expressions.

Instead of having to check and do the change, you write an expression, the calculation formula, sort of. This calculation needs to be executed with the current state version, without access to the previous one.

Imagine a formula:

a = b + c


b = 10
c = 20


a = 10 + 20
a = 30

If I use this expression 1 million times, passing b as 10 and c as 20, I will get the same result. This is a pure calculation. React performs the same principle. All calculations of derivations should be pure.

But why it matters?

React work in re-renders. Each cycle generates a description of the UI and based on the differences between the current one and the next one, it commits changes to the DOM. Each render is completely separated from the previous or the next.

UI = fn(state)

So for each different state version, we got a different UI version. This becomes pretty confusing if we add previous values here. Because now it does not just depend on the state, but on the previousState as well. Instead of having one source, one expression and one result, I can have multiple sources, maybe more complex expressions to handle these sources and inconsistent and unpredictable UI as result.

Each render will behave differently based on the previous state. And as some of the possible implementations of usePrevious rely on time ordering in React, this becomes more dangerous.

With concurrent features, React can stop without warning a render, to prioritize other actions. Depending on useEffect and ref can make you keep a stale version of a “previous” render that is even the real previous one. More mess to reason about.

Memoization

Think in an expression like this

a = b + (c - d)

One part of that has priority and needs to be calculated before, let’s think it with javascript code:

const cdResult = c - d;
const a = b + cdResult;

So now we have two separated expressions that can be calculated separately, and are perfectly pure. But if the value of b changes a lot and the calculation for cdResult is expensive, how can we solve it? Memorizing!

const cdResult = React.useMemo(() => c - d, [c, d]);
const a = b + cdResult;

Now cdResult will just be recalculated if c or d changes.

But above in the text I said there is no previous value, but how can a calculation of one render be used in the next one? This doesn't break the purity of calculations?

Actually, no. For example:

// render 1
// c = 30; d = 20
const cdResult = React.useMemo(() => c - d, [c, d]); // = 10

Imagine we are in the render number 1. The c has the value of 30 and d has the value of 20, so the result is 10. But as I am memoizing it, React will keep track of the dependencies I added on the array. If some of them change, it recalculates.

// render 2
//  c = 30; d = 20
const cdResult = React.useMemo(() => c - d, [c, d]); // = 10

But they didn’t change. If I call this expression again, with c as 30 and d as 20, I will get the same 10 as result. Even though I am in the render number 2 and other variables have changed, the dependencies I use in this calculation didn’t change.

I can calculate it again in each render, it’s the default behavior of React, but I can choose to skip an unnecessary recalculation that will return the same value, so I kept it. We kept the purity and we kept the separation between renders

Previous state

But there is a good place to do logic with previous state, user actions. Of course, that in the moment the callback is called, that would be the current state. But if you have some state that needs to change based on some logic, it’s the place.

Of course it can have very specific cases where maybe you need a hook such as usePrevious, but be aware of the inconsistencies it can cause, and try to add guarantees to avoid bugs on the application.

And more importantly, if possible, avoid it.

Reasoning about the useEffect wrong usage

Felipe Gustavo — Fri, 06 Dec 2024 23:38:17 +0000

The most wrong used hook in React is, for sure, useEffect. We have multiple reasons for this, not just one. Let’s explore each one of them, from my point of view.

Lifecycle legacy

So one of the reasons I think has more impact is that, in the pre-hooks era, we used classes. For those who started to use React in this period, it’s used to use lifecycle methods and this.state. I wrote a little about this in this post. There are people that miss the old but gold classes period, and value its simplicity and directness. It’s a model that fits pretty well with the common knowledge of programmers in general, that learn object oriented and imperative programming, and the mental structure just connects with that model.

Then they added hooks.

Paradigm mental shift

The problem is the paradigm shift that happened. Programmers in general are very familiar with the imperative and the object oriented paradigms, they are commonly teached on colleges and courses, mainly the imperative one, follows the common flow of thinking of a human being.

When you switch to different paradigms like functional programming, you face a reversed way of thinking, that is not so close to the common one. This “reversion” makes it more difficult to understand.

Reactive programming suffers the same issue. It’s a change from an active to a passive way of doing programming. We see it with the wrong usage of useEffect.

Most of the "ERRORS" are state syncing. So, the dev uses the useEffect to track some state or prop and based on some logic, to change the state. This case reveals the opposite way of thinking we need here.

In OOP and imperative programming, you are active, doing the changes and logic in a proactive way. Reactivity is based on the opposite, you react to a chance, and declare the calculations you want the system to do when the state changes.

For most of the users, to actively set the new state on the useEffect is the direct way, the state changed, so you need to manually track the change and update other states with it. The docs say it’s NOT recommended, but there is no clear reason for this.

To derive in React is the recommended way not just for performance reasons, but for a conceptual one. React is a derivation machine, and the result, in the end, is the derivation of the UI. You don’t need to actively handle these state transitions and recalculations, it just happens, based on the declarative code you wrote.

React docs didn’t explain this very well, after hooks, React core team and content creators didn’t make talks or courses explaining these concepts.

React’s conceptual confusion

React seems to have a “conceptual confusion”, the transition to hooks is the most strong example of it, but not the only one. There is one big difference on the usage of hooks, it’s based on reactivity, and even though the React core team jokes about reactivity, it was their decision to switch to it.

Functional components are perfect for it. Each re-render calls again the function, and everything inside gets the state and props current version, so, everything created inside behaves like a derivation. The return, the JSX, is the derivation of the UI.

But React is not the perfect and pure implementation of functional programming and reactivity. It takes concepts and ideas as inspiration and merges them creating their own model, but the core is there, anyway.

And this needs to be clear. Even without being the example of reactivity, it uses their concepts, and to know deeper the patterns make it easy for a developer to think and create solutions with those primitives. That’s why I’m writing this “Reactivity in React” series, by the way.

Not just say to the users, “don’t sync state on useEffect, it’s bad”, but explain why it’s bad and how to think in a way that “sync state” is even the first solution thought.

Lack of some primitives

This cause is one that is improving, especially in React 19. Async derivations was one of the causes to use useEffect, but now we will have to use primitive, which fills this gap in some ways.

Of course, we still have some weak spots in the primitives, such as the case for dynamic derivations, and other cases, but more and more React moves more the side effects out of hooks field, as this case of ref callbacks.

And we can always hope for news in the future. I invite everyone to read all other Reactivity in React posts and bring specific cases and questions, we can explore and find more solutions to these common problems with reactivity.

The death of useEffect and the dynamic derivations role in it

Felipe Gustavo — Wed, 27 Nov 2024 13:44:10 +0000

The title is a little “click bait”, but the idea is not wrong.

I don’t have the opinion that useEffect is a bad hook, actually it is quite the opposite. But in React, which works as a derivation machine, to use useEffect for state sync is not the best option, and not recommended by the core team.

But wait, and if I have the case where I need to sync a state?

Yes, it’s very rare cases and perhaps there are better solution options, but imagine we have a post in a app and we want to have a local state to handle optimistic updates, when the user clicks on like button, but that it syncs with external state (coming from backend) to really know if the like happened.

Mutable derivations

This is a case where we need a primitive where we can do state and derivation at the same time. Conceptually speaking, we can think of it as a mutable derivation. Ryan Carniato has a good blog post about it, but there are some limitations related with React way of managing reactivity, but this new primitive would be derivation and state in just one:
Derivation as the default behavior, getting the last updated source of truth (the data prop coming from server).
State when the user clicks on the like button. This change is temporary and will be overwritten on the next dependencies change.

We don’t have it on React, of course, but we can imagine a primitive like that. The positive points of it:

it removes one more use case from useEffect.
it makes clear that we have a derivation that can be handled as a state.

useMemoState

const [internalState, setInternalState] = useMemoState(() => data, [data]);

The hook accepts two arguments like a normal useMemo, being the first one the memo function, that would execute on the first time normally, the returned value will be the state. The second argument is the well known array of dependencies, to keep track of the values and re-calculate the memo if necessary. It returns a tuple with two values, the state/memo value and the setter that would change the state temporarily.

Using the hook would be like this example:

function MemoState ({ data }: { data: State}) {
  const [internalState, setInternalState] = useMemoState(() => data, [data]);

  return (
    <section>
      <p>name: {internalState?.title}</p>
      <p>{internalState?.like ? "liked post" : "not liked post"}</p>
      <button onClick={() => {
        // likePost();
        setInternalState(state => ({
          ...state,
          like: !state.like
        }))
      }}>Like Button</button>
    </section>
  )
}

This way you remove the need of a useEffect here, knowing exactly what this hook is doing and is capable of, and fill this conceptual gap, where our problem needs a state and a derivation at the same time. Ironically, it removes the need for an effect as a consequence.

How can we do something similar in React?

In order to follow React rules and keep the hook safe, we will need to use useEffect to create something similar in today’s React. I don’t think a hook like that will be made in the future, but who knows, right?

To avoid the usage of useEffect here, we will need to use some external code like a mini state library to handle it, or if we want to keep strict React primitives, to use useRef to keep sync of values.

The problem with this approach is that it breaks React rules, and it’s not recommended by the docs. Because the only way for it to work without the effect, would be to sync the refs during the render of the component, not safe at all.

So, to keep it simple and safe, a example of hook would be like that:

const useMemoState = (memoFn, depsList) => {
  const [state, setState] = useState(() => memoFn());

  useEffect(() => {
    setState(memoFn());
  }, depsList)

  return [state, setState];
}

Lifecycle doesn't exist in React with hooks

Felipe Gustavo — Tue, 12 Nov 2024 14:08:24 +0000

A long long long time ago, we used React with classes, remember?

At that time, we had the concept of lifecycle methods, methods on the classes that accepted callbacks that would be executed in certain moments. The big three: on mount, on update and on unmount.

Old, but gold classes

That was important, on the classes components the returned JSX was made on render method, the state attached to the this of the component, and the app developer needed a way to know to do actions in certain moments. We had the idea of the time on the life of a component:

componentDidMount is the moment the component renders for the first time and adds elements to the DOM and is the moment to start connection and side effects such as API requests.
shouldComponentUpdate allows you to manually set your logic to compare the next props and state and return a boolean to define if the re-render could be skipped or not.
componentDidUpdate is the moment the state or props changed, calling render method again and doing the reconciliation changes to identity difference and apply to the DOM, good to sync state with new props and do logic stuff.
componentWillUnmount is when React would remove the elements from the DOM and was a good place to clean things and avoid memory leaks.

And of course, you had an important API such as forceUpdate, that allowed you to manually trigger a re-render if you are using external data that would not connect with React state updates.

At a conceptual level, we have a more direct way of conducting the flow of the app. The lifecycle methods followed a similar life cycle of a DOM element, you could do memo and forceUpdates by yourself, syncing state was the default way of doing logic.

This directness was seen as simplicity, and to learn these concepts was easier compared with the reactive model. But then, hooks arrived and changed everything.

The unnamed reactivity

The transition was confusing. First, in a search to make it easy, and sort of, maintain the conceptual vision of React model that devs had, a lot of communications tried to show the similarities on the hooks model. To have the 3 main life cycles methods, they showed workarounds with useEffect.


// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

So, most of the new React code made with hooks followed this idea, and starting to sync state was a natural process. In order to keep the same idea of lifecycle methods, it was the place to call setState and trigger the re-render process.

What is the problem with it?

Syncing state became a problem, the wrong usage of useEffect became a problem, double re-renders became a problem, too much re-renders became a problem, performance became a problem.

It’s a little bit confusing this step from React, at least for me. Because, the move to hooks was a move to a reactive model, even if it’s a coarse-grained one. But the communication was that nothing really big changed. No content about the reactivity concepts and theory, even working for years with React, I just started to really understand reactivity reading Ryan Carniato’s blog posts about reactivity and solid.

Even knowing that useEffect had a misuse, I really didn’t understand why, and this lack of conceptual theory about reactivity makes committing mistakes with hooks so easy. useEffect became the most hated hook, being called “useFootgun” for some people. The point is, there is a conceptual confusion in React that expresses itself as all the issues with useEffect we see today.

useEffect issues are not the cause of the problem, but the consequence.

What about life cycle with hooks

So, this is the thing. There is no life cycle in the concept of reactivity.

You have a change, you react to it deriving and doing side effects. Effects are the consequence, not the cause. There is no state sync and no concepts of mount and unmount.

It should not matter if it is the first, the 10th or the last render before unmount, and the hooks don’t care for it, by the way, even useEffect.

Try it:

function EffectExample() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect', count);

    return () => {
      console.log('clean up', count);
    }
  }, [count]);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

You will see on your console both functions being executed on each state update. First the clean up one, and then the effect callback. If you are using useEffect with some state or prop to do a subscription, every time the dependencies changes, the clean up function will be called, and then the new callback, doing the subscription again, but with the new values.

You should look your app code as the React model simplified:

UI = fn(state)

If you have a component like this one:

function Example() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

what you really have, when you click on the button and adds +1 to the count, conceptually, is something like this:

// first render
<button>0</button> = fn({ count: 0 });
// button click - re-render
<button>1</button> = fn({ count: 1 });
// button click - re-render
<button>2</button> = fn({ count: 2 });
// button click - re-render
<button>3</button> = fn({ count: 3 });

Each click calls again the fn, with a new state, generating a new version of UI. The state should change by the action of the user or by an async value that should be made with async derivations.

This way you keep the clean idea:

state transitions make a new fn call
with the new state, you get the UI description
if it’s different, update the screen.

A clean and consistent model.

it’s a matter of the renderer to care with adding, updating and removing elements from the screen. At the component level, what matters is:

if the state changed
if the app can handle the user actions
the returned structure in the JSX.

Hooks and its reactive model make React decouple itself from the browser, making the app code care less about in which moment of screen rendering process you are. You don’t force updates and even handle memos by your own rules anymore, it's less direct for the app dev, but more direct in terms of model.

Each re-render generates a structure, React takes care of the rest.

Async derivations in React

Felipe Gustavo — Thu, 07 Nov 2024 02:37:43 +0000

We have a problem, async is hard.

Imagine you have a simple GET API, a search that receives as param a searchText. You call it using your http request tool of preference and get a promise, it resolves to the list of whatever you are searching for.

How can I call it in a React component?

First of all, it’s important to notice one thing, what I described can be modeled as:

result = await searchAPI(searchText);

Let’s get conceptual here. This is a derivation. For each version of searchText, you can get a different result. But there are some problems here:

it 's external data.
it returns a promise.

How can I call it as a derivation in React?

Using third-party libraries, such as TanStack Query and SWR solves our problem. They give us hooks that we can use in a React component, receiving our states and props and recalculating (refetching) to the API when it changes. Look this example:

const { data: searchResult, loading } = useQuery({queryKey: [search, searchText],queryFn: getSearch,});

Ok, we solved async derivation, right?

Not really.

By the way, I always recommend just using one of these libraries, they are awesome and save a ton of time with more complex cases (such as refetching, retry, cache control and etc), but we cannot count on a third-party to solve a conceptual problem of React.

Coming again to reactivity, we need to have a way of dealing with asynchronous cases in a derivation model. React should give us a primitive for this case. Well, until version 18 we didn’t have it, but in 19 it’s different.

The ‘use’ case

React 19 introduces a new primitive called use. Yes, the naming is a little confusing, but its role on the reactivity model of React is pretty important. With it, we can solve promises during the render of a component. The missing derivation.

Before it, the only way of calling a fetch during the render of a component was to use useEffect, call the promise and on the then clause, set a state with the value that comes as response. That worked, sort of, but we had all the problems of using an effect to do it.
The use primitive allows us to resolve the promise during the render of the component, allowing for us to use the state and props to create the promise, and then, resolving these promises and using it on our functions and JSX.

const useCountTotal = (count: number) => {
  const countTotalPromise = useMemo(() => genericPromise(count), [count]);


  const result = use(countTotalPromise);


  return result;
}


function AsyncDerivation({count}: { count: number}) {
  const result = useCountTotal(count);

  return (
    <div>Total count is: {result}</div>
  )
}

At the moment I’m writing this, we don’t yet have the final release of React 19. There are some caveats and probably the primitive will evolve in the future to work in more places.

One specific thing of the primitive use is that it needs to be used with Suspense and there is a very good reason for this.

Async and React components

The conceptual idea of await is nice, but it has a flaw when joined with React components. You cannot just use await during the render. React calls a component to get the JSX response and use it on their flow to render a UI.

If we could just stop everything in a await, React could not access the children of that component and continue its work until the end of the tree. We’d stop the render flow and make the UI not be updated and freeze.

How to solve that?

We can look at the two examples I used in this article. The first one takes the approach of returning flags such as loading, not blocking the render flow. When the promise is resolved, it throws a re-render, updating the flags, the loading turns false and data receives the response data.

The use approach is different. It really behaves like the await primitive, so the component render flow is stopped there, until the resolution.

Wait, wait, wait, you said it was a problem, right?

And here it comes Suspense for salvation. When you use the use primitive, it’ll be wrapped in a Suspense component, the render flow will stop waiting for the use resolution, and the user gets the fallback rendered on the UI (normally a loading spinner or skeleton, something to indicate we are loading some stuff there).

When the use promise is resolved, we continue the render and update the UI accordingly. No need to use useEffect.

Conclusion

The use primitive will be very useful for library authors aiming to use Suspense and work with asynchronous behavior. For the app developer, it fixes one more case in the basic reactivity model, that will fit great in simple use cases. As it wraps promises, it is not restricted just to http requests, but for all async cases and external API usage, which can add more resources to the ecosystem.

The complicated relation between React and derivation

Felipe Gustavo — Tue, 29 Oct 2024 22:40:58 +0000

React hooks was released 6 years ago, but until today, we can see errors being committed, even by senior react engineers. In the newest version of React docs, the core team put a strong effort in teaching the wrong use cases of useEffect, but errors continue happening in real projects.

In this post, let’s try a different approach. Let's understand React relation with derivation and why you should use more of it.

Reactivity

React is not fully reactive, but in the end, to the developer creating apps, it doesn’t matter so much. The point of difference here is that the coarse-grained approach React follows creates the necessity of re-renders to really identify what changes the state transition created.

So, think in a simple React component like this one:

function Example() {
  const [count, setCount] = useState(0)
  const text = `count is ${count}`;

  return (
    <button onClick={() => setCount((count) => count + 1)}>
      {text}
    </button>
  );
}

When we change the count state, calling setCount, we update the state value and schedule a re-render. All right, React will re-render this component calling it again. At this moment, if I ask React what changed on the render, what should be the answer?

Probably a humble “I don’t know”.

React doesn’t track its state with a complex data structure managing its dependencies like other fine-grained reactive libraries do. React needs to call the component again. In this new call, the count constant created will have the new value, and above it we will create a new constant with the string, for example “count is 1”, if count value changed to 1.

Then the JSX will generate its structure with one change, the button inner text is not “count is 1”, React does the reconciliation process, identifies this change and applies it to the real DOM. Obvious, right?

At this moment, if I ask React what changed, it will probably answer: “The button text from Example component”.

But wait, what about the text constant? It changed as well, why does it just matter the v-dom (I know the problems with this term, but it's how it is commonly called) structure it created?

For React, it doesn’t matter the variables and constants you created internally. What matters is the state changes and then, the return of the component call.

Everything in the middle is part of the process of creating the view structure. Of course, all this data can affect the return JSX, and that is the point of the React model, caring about the result of the component calls and updating the DOM accordingly with the view.

You probably saw the simplification of React model as:

view= f(state)

View as the result of function of state. View in this case is a derivation that changes based on state. So, for this term and for the internal component data, React is a derivation machine.

Derivation Machine

Every variable and constants you created inside a component will just be alive during that component call. In the example we used above, every re-render of Example components created a new constant text. If I need to have a new value based on some props or state, it will just create a new variable using those states and props in the calculation.

React creates derivations automatically, by default.

Let’s take an example from React docs:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  // 🔴 Avoid: redundant state and unnecessary Effect
  const [fullName, setFullName] = useState('');
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);

  //...
  return <span>{fullName}</span>;
}

We have some issues here. First of all, the nature of a state.

Why do we need a local state like this in an app? To keep the data and allow the user to change it. The fullName state is not being changed by the user, but by the useEffect. It’s using other states to create a new value. Again, in React, every variable and constant we create internally in the component can use the states and props to calculate its value: a derivation, the default behavior of React.

There is another problem with this example, about runtime. In this case, in the first render, the fullName value will be an empty string. React will get the return of the JSX of this component, render it to the UI, follow the browser painting process and after it, call the useEffects of the components. At this moment we will have the setfullName call, which will schedule a new re-render. React will call the component again, now with the fullName as Taylor Swift and then, update the UI with the new text value.

In terms of runtime, you are doing 2 renders, one of them an unnecessary one, with wrong data. It’s worse in terms of performance and stability, because the user will see the value as empty and it can be seen as a visual bug.

So, following the React derivation model, we can simply change it to:

function FormRight() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  const fullName = firstName + ' ' + lastName;
  //...
  return <span>{fullName}</span>
}

Now we have just 1 render, avoiding the unnecessary one. And we will avoid the use of the effect just using a derivation. That will be updated on every re-render using the latest version of the state values.

But if the calculation is too expensive? Or if I have too many states and want to update the fullName just when firstName or lastName changes?

Right, in this case just use useMemo, adding the same array of dependencies you were using on useEffect. The memoization model of React is just a way to avoid the default behavior, that is to create a new derivation on every re-render. With useMemo, you track manually the states and props and just create the derivation again if some of them have changed.

What about useEffect?

useEffect is necessary for external sync on values changes. On UI development, there are very few rare cases where this makes sense, because normally the external changes, such as server API calls, happen on user actions (we are creating User Interfaces, by the way), so these will happen on event handlers, not in a useEffect.

If you are using useEffect to update a state, probably you can do the same update using derivation, avoiding all the problems mentioned before.

If derivation doesn‘t work, or you have one of the few specific cases, or something is wrong with the state's design or with the solution itself. There is no problem with it, but in these cases, it’s better to review the component and avoid future problems with the component code.

This is the basics about derivation in React, but we have something missing here.

What happens when I need to do a derivation that is asynchronous, like a simple GET request, that uses some state as param and needs to be recalculated every time the state changes?

This is a topic for the next post.

See you!

What was the starting point for becoming a mid-level frontend engineer?

Felipe Gustavo — Mon, 06 Sep 2021 00:16:03 +0000

Introduction

There are some turning points in our lives that change our way of viewing things and the future. One important of mine is the podcast that I heard in mid-2014 that made me take a technical computer course and brought me to this software’s world.

After that, I went to college, started to work as a junior programmer and arrived at the position that I am today, as a mid-level frontend engineer.

I need to make a disclaimer here: this is not a guide or something like that, it is just a little of my experiences.

The initial step

So the year was 2019, I was working at that time as a junior frontend developer to a big corporation in Brazil. That was the first time working with a big product and I had some knowledge about React, but I didn’t have experience working in real apps and the whole frontend of that company was in React.

It is important to gain knowledge and practice a lot to become faster in building things and solving problems, but this is a natural process that can be accelerated if you practice more and study a lot.

But when I was a junior, all the sprints had stories that scared me, I felt like I was not capable of doing that.

What was that fear?

The lack of experience was what makes everything seems harder than it actually is. This creates a fear of doing something wrong, like creating bugs on production or even in a development environment.

At this point, deadlines were other terrifying stuff. Will I be able to deliver everything until the end of the sprint? Will I be able to solve this issue? Am I being a bad developer by asking help for other developers? It is normal to ask yourself this type of question, and answering them now: No, it is normal and part of the process.

Another thing that I remember of that time was that I looked for the tools that I used, and as I did not really understand how that worked, they looked like magic things.

At that time, I used React and Redux. Creating a reducer looked like rocket science for me. I did not understand how that was created, how that worked in reality, why I had to create a pure function and what the hell is a pure function? React looked like alien technology and so on.

This causes fear too, because we fear the things that we did not understand.

This point connects to the next phase.

Turning point

I was working, having to pay the bills and live, so I had time to study with less rush and stress. I followed the path that goes deeper in the base of frontend development:

CSS: I did an advanced course about CSS. That teached me how css works behind the scenes, how the box-model worked, grid, flexbox and Sass. That gives me confidence in styling applications.
HTML: I studied about semantic HTML, HTML5 and a little about accessibility.
JavaScript: I read the book series “You don’t know JS”. 6 books that explain a lot about the base of the language. That changed my way to code javascript.

The more that I studied, the more I was confident to get harder tasks at work and improve my ability to solve issues and participate in meetings.

But I had a real turning point that changed a lot my behavior and my vision about programming, tools and software development.

It was an in-depth blog’s article that talks about reverse-engineering, the gains of doing that and a guide of how to do that. This blog taught me a lot, they had a lot of advanced and deep articles about React, and other frameworks, like Angular.

Talking more about this article, after reading it, a wall of fear broke in my head.

The article explains how to learn about how a library works by reading its source code and tracking the use of the library, organizing the points of study and creating an environment to use tools like devtools to do this work.

Those tools, like React and Redux, that was magic for me, were shown as just a bunch of code, with great logic, patterns and structures, of course, but in the end, it is just code.

Code that I can read and understand, using data structures and design patterns that I can learn and use. After reading those articles, I started to look at source codes and learned how to build software with it.

I lost that fear.

And the confidence with the knowledge makes me more comfortable to use that and start to help others. At work, this makes me start to take harder tasks and carry projects alone, which, in the end, made me become
a mid-level developer.

I’m not saying that this path is simple or something like ‘read this article and you will become a mid-level developer in a few months’. This is not so simple, and getting a promotion does not even mean that you really achieve a higher level of experience and knowledge.

But the whole point of this post is to recommend the in-depth article, and try to bring this point of view, that it is not something that we saw in other places.

Here in dev.to and other tech publications we saw a lot of the same type of content. A huge number of beginner's guides of technologies, the same discussions and explanations of the same topic. But how many times have you seen an extensive and deep post explaining how a library or framework works behind the scenes?

Look at a big codebase and understand that at the point of being able to write and explain that is not simple. It is hard to do, takes a lot of time, but can be rewarding:

Having in-depth knowledge about a library can make you an expert on that and maybe become a specialist.
You can contribute with that project and that can bring opportunities to you in the future.
You can create advanced content about that, a type of content that we do not have in a good number.

Research source:

Understanding how the redux data flow really works

Felipe Gustavo — Thu, 19 Aug 2021 14:58:51 +0000

Introduction

Redux is one of the most used state management libraries available today for web applications. Most of the developers use that, but did not know how it works behind the scenes.

Some time ago I decided to read the Redux codebase, to better understand the implementation of the library that I used in some jobs. In this work, I did some notes, and this article is a more complete version of that.

Disclaimer: This article tries to be a deep dive into Redux. It is not a tutorial and it requires a basic knowledge about Redux, the idea here is to understand the internals and not teach how to use.

Dataflow

The data flow of Redux is the base of the library. It is one of the first things that we learn when we start to study Redux.

You dispatch an action, that is a plain object, to the store. This updates the state using the reducer function and this new state returns to the application, updating the UI.

One important thing to understand here is the architecture of Redux. It consists of the core that handles the basic features, such as dispatch actions, update the store and notify the state updates.

Another part is the bindings, the most popular one that is supported by the Redux core team is the React one, called react-redux. This module connects the Redux core to react applications, creating HOC and Hooks that the react developers use to develop the UIs in the end.

Our focus in this article will be the Redux core. Mainly, the store object. There is the place where the state tree is created and where it is provided the dispatch and subscribe methods. The both are the most important methods to Redux data flow work.

To create the store, you have a function called createStore. This function accepts 3 arguments:

the reducer function.
the preloaded state object or most known as initialState. This is useful for universal apps or SSR applications, because it allows the user to add a first state before the hydration process. Another use for this is when some library stores the state in local storage and reloads the state in the next section.
the enhancer (this is the argument that allows the use of middlewares, and will be the theme of another article).

In the creation of the store, the function does a lot of verifications to see if the reducer passed is really a function and if the preloadedState is a real object.

if (
    (typeof preloadedState === 'function' && typeof enhancer === 'function') ||
    (typeof enhancer === 'function' && typeof arguments[3] === 'function')
  ) {
    throw new Error(
      'It looks like you are passing several store enhancers to ' +
        'createStore(). This is not supported. Instead, compose them ' +
        'together to a single function. See https://redux.js.org/tutorials/fundamentals/part-4-store#creating-a-store-with-enhancers for an example.'
    )
  }

  if (typeof preloadedState === 'function' && typeof enhancer === 'undefined') {
    enhancer = preloadedState as StoreEnhancer<Ext, StateExt>
    preloadedState = undefined
  }

  if (typeof reducer !== 'function') {
    throw new Error(
      `Expected the root reducer to be a function. Instead, received: '${kindOf(
        reducer
      )}'`
    )
  }

Then, the function returns the store object.

Internally, they create some important variables, these variables work as properties of the store object.

let currentReducer = reducer
let currentState = preloadedState as S
let currentListeners: (() => void)[] | null = []
let nextListeners = currentListeners
let isDispatching = false

currentReducer: this variable receives the reducer function argument, that will be used to create the new state.
currentState: this variable will keep the state itself, it starts receiving the preloadedState, but can be updated by other methods.
currentListeners: this variable keeps the array of listeners, that is callback functions that are executed when the state is updated. (we will dive deep into this topic later in this article).
nextListeners: this variable works as a temporary list to new listeners, to avoid some bugs when new listeners when a dispatch or notify work is in progress.

isDispatching FLAG

The redux library has a lot of verifications, but one appears a lot of times: this is the verification of isDispatching. The idea of that is to prevent changes on the variables when the dispatch function is being called. The point is to prevent bugs with changes being made on the execution.

The default value is false. The value is changed to true inside the try that updates the state. At that moment, if other methods as getState, subscribe, unsubscribe, dispatch are called, this function has verifications that throw an error, warning that these methods can not be executed correctly at that time.

See an example of isDispatching verification below:

if (isDispatching) {
  throw new Error(
  'You may not call store.getState() while the reducer is executing. ' +
      'The reducer has already received the state as an argument. ' +
      'Pass it down from the top reducer instead of reading it from the store.'
  )
}

Returning to the dataflow, it can be divided in 2 big parts:

Dispatch action and update state.
Notify state change to subscribers.

Dispatch

As shown on this basic example of Redux Documentation (https://redux.js.org/introduction/getting-started#basic-example), after using createStore and having the store object available, the way to dispatch an action is to call the dispatch method.

function dispatch(action: A) {
  if (!isPlainObject(action)) {
    throw new Error(
      `Actions must be plain objects. Instead, the actual type was: '${kindOf(
        action
      )}'. You may need to add middleware to your store setup to handle dispatching other values, such as 'redux-thunk' to handle dispatching functions. See https://redux.js.org/tutorials/fundamentals/part-4-store#middleware and https://redux.js.org/tutorials/fundamentals/part-6-async-logic#using-the-redux-thunk-middleware for examples.`
    )
  }

  if (typeof action.type === 'undefined') {
    throw new Error(
      'Actions may not have an undefined "type" property. You may have misspelled an action type string constant.'
    )
  }

  if (isDispatching) {
    throw new Error('Reducers may not dispatch actions.')
  }

  try {
    isDispatching = true
    currentState = currentReducer(currentState, action)
  } finally {
    isDispatching = false
  }

  const listeners = (currentListeners = nextListeners)
  for (let i = 0; i < listeners.length; i++) {
    const listener = listeners[i]
    listener()
  }

  return action
}

The dispatch method is a simple function with only one objective, update the state.

It receives a plain object as an argument called action. It is mandatory to have a property called type on the action, this type will be used on the reducer to identify the script that will create a new version of state. To make sure that an action used on the dispatch call follows these rules, Redux does some verifications with the action argument.

if (!isPlainObject(action)) {
  throw new Error(
    `Actions must be plain objects. Instead, the actual type was: '${kindOf(
      action
    )}'. You may need to add middleware to your store setup to handle dispatching other values, such as 'redux-thunk' to handle dispatching functions. See https://redux.js.org/tutorials/fundamentals/part-4-store#middleware and https://redux.js.org/tutorials/fundamentals/part-6-async-logic#using-the-redux-thunk-middleware for examples.`
  )
}

if (typeof action.type === 'undefined') {
  throw new Error(
    'Actions may not have an undefined "type" property. You may have misspelled an action type string constant.'
  )
}

Basically, it verifies if the action is a plain object, calling a util function called isPlainObject. Then, it verifies if the action object has a type property and if it is undefined. In these cases, they throw Errors to warn the user.

try {
  isDispatching = true
  currentState = currentReducer(currentState, action)
} finally {
  isDispatching = false
}

After the verifications, they do a try statement to update the state. First, they update the isDispatching flag to true (as we explained above), and then, they call the reducer function passing the last version of the state variable and the action object.

The reducer will get the type of the action and based on that, will create a new version of the state. Then, they return this new state and that is assigned to the currentState variable.

This part of the code is inside a try statement, so basically, if the reducer function throws any error, this does not break the redux work. This makes the code safer on runtime. Finally, they update the isDispatching to false, to maintain that work of the isDispatching flag verifications.

Another important point here, that explains the reason that Redux documentation says that the reducer function has to be a pure function, can be understood here. As you can see, Redux uses a simple variable to hold the state and use this variable as argument to the reducer function.

As the state is an object, it is a reference pointer, so if you mutate the argument on the reducer function, you mutate the currentState variable that is inside the store. And as the return of the reducer will be assigned to the currentState variable, if you mutate that, will basically set to the same reference that was assigned before.

It generates some issues as:

Break time-travel features because all state changes, that should create different state ‘versions’, will be always the same, with the same content.
Can cause bugs related with the huge number of mutations and reassign to the same reference at the same time.
Can impact on changes verification, because some libraries, such as react-redux, for example, use shallow equality as the way to compare changes, as shallow equality relies on reference comparison, sometimes the state changed, but will not cause updates and re-renders.

After all this state update, they need to run the listeners to notify the subscribers that the state changed. We will talk more about this in the next section.

Notify

The notification process of Redux is made by the method called subscribe. It is basically an observer design pattern, this method allows adding a listener function that is executed after a state update.

We can see the hole code of the subscribe method below:

function subscribe(listener: () => void) {
  if (typeof listener !== 'function') {
    throw new Error(
      `Expected the listener to be a function. Instead, received: '${kindOf(
        listener
      )}'`
    )
  }

  if (isDispatching) {
    throw new Error(
      'You may not call store.subscribe() while the reducer is executing. ' +
        'If you would like to be notified after the store has been updated, subscribe from a ' +
        'component and invoke store.getState() in the callback to access the latest state. ' +
        'See https://redux.js.org/api/store#subscribelistener for more details.'
    )
  }

  let isSubscribed = true

  ensureCanMutateNextListeners()
  nextListeners.push(listener)

  return function unsubscribe() {
    if (!isSubscribed) {
      return
    }

    if (isDispatching) {
      throw new Error(
        'You may not unsubscribe from a store listener while the reducer is executing. ' +
          'See https://redux.js.org/api/store#subscribelistener for more details.'
      )
    }

    isSubscribed = false

    ensureCanMutateNextListeners()
    const index = nextListeners.indexOf(listener)
    nextListeners.splice(index, 1)
    currentListeners = null
  }
}

In the subscribe method, first, it is made 2 basic verifications, one for the isDispatching and another to the listener argument, verifying if the type of the argument is really a function, to make sure that it will not break when it is called on state changes.

Then, it came to the main point of this function: add a new listener as a subscriber.

let isSubscribed = true

ensureCanMutateNextListeners()

nextListeners.push(listener)

To do that, first they create a variable called isSubscribed assigning to true. The idea of this variable is to keep the internal state of that listener on the subscribers array, if it is there or not. It is important to notice that the return of the subscribe function is an unsubscribe function.

So, using the concept of closure, this variable isSubscribed is held in this unsubscribe function. The idea is use this variable as a verification, if the listener is subscribed, the function executes the work to remove this listener from the array, if not, then do nothing.

return function unsubscribe() {
  if (!isSubscribed) {
    return
  }
...

Besides that, other 2 functions are executed:

One called ensureCanMutateNextListeners
The push of the nextListeners array, that actually adds the listener to be executed in the future.

About the ensureCanMutateNextListeners:

function ensureCanMutateNextListeners() {
  if (nextListeners === currentListeners) {
    nextListeners = currentListeners.slice()
  }
}

To understand this function, we need to understand the difference between currentListeners and nextListeners.

currentListeners: is the variable that keeps the listeners that are being executed or that were executed on runtime.
nextListeners: is the variable that keeps the next version of listeners to be executed. This is the variable that gives the push on the subscribe function, to add a new listener. On the dispatch function, after the state update, the currentListener receives the reference of nextListeners, so if there are new listeners, they will be executed.

The point of this function is that after the dispatch, the nextListeners and currentListeners are basically the same, pointing to the same reference. The issue is that if we just give a push to nextListeners, we are affecting the currentListeners variable and if a dispatch is happening at that moment, it can cause bugs.

To avoid that, they created this ensureCanMutateNextListeners function.The idea is just do a shallow copy of currentListeners, creating a new reference. This way, if we update nextListeners, we do not affect currentListeners.

Finally, to close the notify process, on dispatch function, after the state update, all the actual listeners callbacks are called.

const listeners = (currentListeners = nextListeners)

for (let i = 0; i < listeners.length; i++) {
  const listener = listeners[i]
  listener()
}

As explained above, the currentListeners receive the nextListeners reference and this is assigned in the listeners variable. Then, they use a simple for loop to call all the listeners. This way, redux notifies all subscribers that a state update happened.

Get state

Imagine that a subscriber is called after a state update and wants to use the new state on the UI. How to do this? There is a function called getState.

function getState(): S {
  if (isDispatching) {
    throw new Error(
      'You may not call store.getState() while the reducer is executing. ' +
        'The reducer has already received the state as an argument. ' +
        'Pass it down from the top reducer instead of reading it from the store.'
    )
  }

  return currentState as S
}

This function is the simplest of the entire library. A basic verification about the isDispatching is executed and after that, it is just returned the currentState variable.

Research source:

Some thoughts about frontend learning

Felipe Gustavo — Thu, 14 May 2020 02:06:12 +0000

Everyday a great number of new people start to study programming and web development. The Front-end is one of the main areas of software development that are chosen by this people. And they have a lot of questions about what framework/library to learn, what tools to use and etc.

But, if I could give an advice to them, I would say that the most important thing is to dominate the fundamental technologies of the web. Become advanced in this technologies, not just learn the basic stuff, because with this solid fundamentals, the path to learn advanced librarys, frameworks and tools will be easier than before.

HTML, CSS & JAVASCRIPT

The three main Front-end technologies hide a trap. Its easy to learn the basics, but hard to learn the advanced concepts and know this advanced content will be the difference in your career as a developer.

We see in great companies developers having problems making layouts with CSS, for not knowing how the box-model works; or not making the app fully accessible for not using a semantic HTML approach. And with the JavaScript this become much more important, because of the peculiarities of the language.

20-80 rule

This technologies use the 20-80 rule. With 20% of the effort you will learn 80% what you need to start to work in the market. The problem is that only know the basics will make you have a lot of issues in problem solving, taking you to difficulties, bugs and errors.

The big problem is that learn this other 20% requires 80% of the effort!

Conclusion

So the advice is to keep calm and go deep in the learning of this three technologies. Please, don’t underestimate the complexity of HTML, CSS and JavaScript. And understand that all that amazing frameworks, that huge number of names and tools is made with this three fundamental technologies.

Template engines like liquid, pug, EJS and etc is converted to HTML.
The pre-processors like SASS and LESS is just CSS with some other features.
React, Angular, Vue is just JavaScript with some design patterns and software engineering concepts.

The learning curve to this hype tools is very low if you have an advanced knowledge in the fundamentals. Here is an amazing website with a list of the topics that is nice to learn in the three technologies and a lot of others too: Web Skills Website

Understanding BEMCSS

Felipe Gustavo — Sat, 16 Nov 2019 07:31:30 +0000

When the use of CSS is no longer just the stylization of personal websites or small projects and moves to large, scalable and complex projects, there is a need to organize and think about the architecture for the CSS. Simple things like class naming can become a huge problem in future maintenance.

To correct problems like these, organizational architectures and methodologies were created and one of the most popular is BEMCSS.

What is it?

The acronym comes from Block-Element-Modifier, which is the way designated to create names for the classes. The idea is to create a rigid standard for class naming, making it easy to read and understand what the class does and what component it targets.
The class names follow the line:

.block__element--modifier {}

Two underlines that separate the block from the element and two lines that separate the element from the modifier.

Block:

The Block is the element or component that that class is assigned to. You don't need to respect the name of the element, the idea is that it describes what the component is in the scope of the project. For example, if you create a class for a login form, the name would not be .form, even though in HTML you do create a form.

In the scope of the project the class could be *. Login *, which would make it clear to everyone what it is about. A general naming rule is to separate compound names with a single dash, for example, *. Formulario-de-cadastr * would be the correct way to write a name with three words

Element:

The Element are internal parts of the component. In the example used above, inside the login block there would be at least two inputs for the username or email, password and an action button.

The appointment of these elements would be:

.login__email {}
.login__password {}
.login__button {}

Modifier:

The modifier usually applies to changes and varied shapes for the elements or for the block itself as a whole. In the example of the article, when the user put something that does not match the password or email in the inputs and there was a check to confirm this, the visual feedback of the error, for example, could be done by changing the colors of the edges of the incorrect inputs to red.

The modifier class would be used to create this, being used in this way:

.login__email--error {}

The modifiers can also be used for the block as a whole, and can be applied directly over it in the class, ignoring the existence of the elements. For example:

.login--error {}

Remembering that each element has its class in an isolated way. For example, if an element has another element within it, it is not correct to join the elements into a single class, such as:

.bloco__elemento1__elemento2__elemento3 {}

In these cases each element has its own class, ignoring the order of the HTML structure

.bloco {}
.bloco__elemento1 {}
.bloco__elemento2 {}
.bloco__elemento3 {}

A new way of thinking CSS:

When using a methodology like BEM, it is interesting to think that you are not just naming classes in a standard way. It is important to rethink how to create the elements, thinking about the layout in a modular way, separating each piece into components, which would correspond to the blocks, elements and so on.

Separating the layout in this way, the creation of the code itself becomes more organized. Using BEM is just the way to formalize this new structure.
It is important to note that BEM is a highly flexible methodology, adapting and fitting in several different CSS project architectures, another very positive point

Conclusion:

The methodology is simple, but very functional and useful in the day-to-day development, in addition to being something that is often requested in job openings in the current market. Creating a scalable and quality CSS avoids rework and increases the quality of a software, therefore, it is an increasingly required skill in high-level projects.

Research source:

getbem