DEV Community: Matheus Vieira do Nascimento

Context API: simple, but dangerous?

Matheus Vieira do Nascimento — Mon, 08 Sep 2025 15:04:51 +0000

Continuing the conversation on state management and optimizations, in a recent post, I discussed using multiple useState hook versus useReducer, and how the false sense of organization can hurt performance and maintainability in React components.

Today, let’s go a step further and talk about another silent performance killer: overusing Context API for dynamic state.

The common and maybe problematic use of Context
You’ve probably seen or written something like this:

On the surface, this looks good. You’re sharing state globally. But this pattern, while common, comes with hidden costs.

The invisible problem
React’s Context was designed for static or rarely changing data, like theme, language, or authentication info.

When used for highly dynamic values like loading states, modals, form flags, or local UI logic, every single change to the .Provider's value causes all consuming components to re-render, even if they don’t use the updated part of the state.

In the example above, toggling isModalVisible will cause a re-render in every component consuming ModalContext.

But what about memo? Doesn’t that help?
Yes, React.memo can help avoid unnecessary re-renders if used correctly, and in combination with useMemo and useCallback to preserve reference stability.

Also, the component consuming the context needs to be memoized with React.memo, and its props must maintain stable references too.

Here’s the catch: this requires deeper technical knowledge and discipline from the developer. While possible, it's easy to overlook small things like an inline function or a value that changes on every render that silently break the optimization.

So yes, the issue can be avoided, but it demands a higher level of attention and care. That’s not inherently bad, but it's risky and easy to get wrong leading to performance bottlenecks that are hard to trace.

When is Context a good fit?
In my opinion Context works great when:

The shared value changes rarely (e.g., theme, locale, authenticated user)
Performance isn't critical
The tree of consuming components is small

More efficient alternatives

Zustand (or other lightweight state managers) One of the best modern solutions. Global scope, granular reactivity, simple APIs, and great performance.

Now, only components that depend on isModalVisible re-render. Nothing else.

useReducer + Context Separating state from dispatch, and using useReducer inside a context provider gives you more precise control over updates.
Lift state locally Sometimes the best alternative is simply to lift state to a common parent and pass it via props. No need for Context at all.

Final thoughts
React’s Context API is powerful, but it's often misused. Overusing it for dynamic state causes a flood of re-renders that impact performance and make debugging harder.

If you're using Context to manage frequently changing values, take a step back and reconsider. Tools like Zustand, useReducer, or simply lifting state locally are often more performant, scalable, and safer.

In my last post, I talked about how useReducer can replace multiple useState hooks with more clarity and control. That same mindset applies here to look beyond the “organized” look of your code and prioritize scalable architecture and real world performance.

*#ReactJS #ReactHooks #ContextAPI #Zustand #CleanCode #Performance #FrontendTips #StateManagement #CodeQuality #JavaScript #Scalability
*
Liked the article? Let me know your thoghts in the comments

Demystifying Git Flow: 'Clean Room' Mode

Matheus Vieira do Nascimento — Thu, 04 Sep 2025 13:30:59 +0000

After several years in the world of software development, code management has always been a cornerstone of productivity and quality. However, who has never found themselves trapped in a tangle of merge conflicts, having to resolve them two or three times a week just to get a piece of code into a testing environment? It's a question that, curiously, often leads to silence, and no one dares to throw the first stone.

The malleability of Git Flow, if not carefully managed, can frequently lead to disorganized or unproductive Git flows. This situation isn't just a technical inconvenience; it represents a significant drain on team productivity and morale, confirming that merge conflicts are a frequent obstacle in development environments.

But why do our Git flows get tangled?

The frequency of conflicts and disorganized Git flows are often symptoms of deeper problems in the branching strategy itself. One of the most common pitfalls is the existence of long-lived branches that diverge significantly from the main branch (develop or main). This substantial divergence makes merge operations progressively more complex and conflict-prone.

Another significant challenge, especially in traditional Git Flow implementations, lies in unwanted dependencies between features. When feature branches are created from develop, and one of them (say, Feature A) is integrated into develop, any subsequent feature branch (Feature B) that updates its base from develop will end up inheriting the changes from Feature A, including potential bugs or unfinished work.

Rethinking Our Git Workflow:
The other day, I was reading some complaints on Slack from colleagues who had to review PRs with nearly 100 changes (and that wasn't even the biggest I've seen), and I started to analyze some recent experiences to gather ideas and build a model to be followed that would bring more peace of mind to the daily grind. That's what I'm going to show you, hoping to help you, whether by following it to the letter or adapting it to your reality. The important thing is that you leave here feeling lighter, with the peace of mind that your Git flow will be better. hehehe

The central philosophy of this adapted Git Flow methodology is based on three pillars: granularity, isolation, and controlled integration. The goal is to break down large tasks, isolate changes, and introduce multiple controlled review points to ensure quality and minimize the impact of conflicts.

Step 1: Every new branch must start from main (or master)

The first and fundamental change from traditional Git Flow is that every new branch must start from main. Unlike the classic model where feature branches usually originate from develop, here, each new feature is started from the stable, released production branch. This directly addresses the problem of unwanted dependencies, where updating a feature branch from develop could inadvertently inherit bugs or incomplete work from other features. This strategy ensures that each feature is completely independent and can only be integrated when it is ready, validating the importance of isolating feature branches for superior control.

Step 2: Fractional PRs/MRs for features – Breaking down cards into smaller subtasks

Instead of a single, large Pull Request (PR) or Merge Request (MR) for an entire feature, the approach is to break down cards (representing features or epics) into smaller, atomic parts. This practice is a direct application of the best practices of keeping commits small and focused and making frequent, small commits. Smaller changes are inherently easier to review, understand, and, crucially, less likely to generate severe merge conflicts. This facilitates review and conflict resolution, and smaller commits make it easier to identify and resolve conflicts incrementally

Step 3: chore branches for subtasks and PR to feature for Code Review

Each of these smaller subtasks gets its own dedicated branch, typically named as chore. Once a chore branch is completed, a PR is opened pointing to its parent feature branch to undergo a code review. This introduces a layer of early and granular code review, ensuring that even within a single functionality, changes are meticulously verified before they are integrated. This step is in perfect alignment with the emphasis on Pull Requests (PRs) and Code Review as essential practices for evaluating changes and reducing the risk of errors.

Step 4: feature to develop only after all subtasks are reviewed

Only after all subtasks of a feature have been completed and individually reviewed (via PRs from chore branches to the feature branch) is the feature branch ready to be integrated into the develop branch (the main integration branch). This ensures that develop receives only code that has already gone through a comprehensive, multi-stage review process. This approach significantly reduces the risk of introducing incomplete, buggy, or unreviewed code into the primary development line, contributing to a more stable develop branch. This echoes the principle of ensuring that only reviewed and approved changes are added.

Step 5: Dedicated feature-dev branch for conflict resolution

This is a highly innovative and practical aspect of the workflow. In cases of conflict between the feature and develop branches, instead of the common (and often problematic) practice of pulling develop into the feature branch to resolve conflicts (which can pollute the feature branch with unwanted changes), a new dedicated branch, feature-dev, is created. This branch serves as a temporary staging area specifically for resolving conflicts between the feature and develop. Once the conflicts are resolved in feature-dev, this branch is then integrated into develop.

This strategy keeps the original feature branch untouched and focused on its core functionality, ensuring that the branch destined for main (production) remains clean and free of merge commits or conflict resolution artifacts. The concept of a dedicated branch for conflict resolution is directly validated by the idea of using conflict resolution branches instead of polluting feature branches.

Step 6: Corrections for QA Testing

When corrections are needed after QA testing, the developer should make these changes in the original feature branch. These corrections should then be pulled into the feature-dev branch. This practice keeps both branches up-to-date and ensures peace of mind regarding the release flow. If corrections for QA testing were made directly in the feature-dev branch, it would be necessary to cherry-pick these changes later to update the original feature branch, which is essential for a secure deployment and to avoid inconsistencies in the code history.

Okay, but what's next?

After that, it's just about being happy. The feature-dev branch moves to other environments that may exist in your work context, such as QA, HML, etc. But at the end of the process, the release starts from main (or master) and receives the original feature branch, clean and free of any suspicion (lol).

Why This Approach Works:
Introducing the feature-dev branch for conflict resolution is a simple but effective application of conflict resolution and a key workflow design element. This approach embodies the principle that prevention is key and that preventing Git conflicts is always better than resolving them. By isolating conflict resolution, you ensure that the feature branch remains clean and focused, mitigating the risk of problems when merging to main for production. (And let's be honest, reviewing 43 altered files at once?! No amount of coffee can get a cowboy excited).

So, have you ever had bad experiences because of a poorly done Git flow?

Have you ever made a slip-up in Git? Me? I've made several, but the important thing is to learn from your mistakes and move forward.

Tell me about your experience and if you liked this concept in the comments!

#GitFlow #VersionControl #SoftwareDevelopment #DevOps #MergeConflicts #Productivity #TechTips #GoodCodingPractices

Pseudo-organization with useState vs using useReducer

Matheus Vieira do Nascimento — Mon, 12 May 2025 21:17:20 +0000

Posted first on my linkedIn
Recently, I’ve seen many discussions about the so-called “mess” caused by multiple useState calls in React components.
The criticism often comes with a proposed "improvement": grouping all states into a single useState with an object, aiming to reduce lines of code and make the component appear more "organized."

At first glance, this idea might seem elegant, after all, who doesn't want cleaner-looking code?But behind this pseudo-organization lie serious issues with performance, readability, and scalability.

The trap of useState with an object:
When you use a single useState with an object containing multiple state flags (like loading indicators), you're essentially linking all those flags to a single memory reference.

In practice:

Every time you update any key in the object, the entire object is recreated.
Even if you use immutable updates (setState({ ...state, changedKey: value })), React sees this as a new full state because the reference has changed.
This causes unnecessary re-renders, even when other properties haven’t changed.
It affects performance directly, especially in components with heavy rendering or many states.

There’s also a readability issue:

You lose individual setters like setIsLoading(true), now you must manually manipulate a shared object.
You lose the semantic clarity of each individual state, hiding them inside a structure that’s harder to reason about.

The illusion of “cleaner code”:
The main reason for adopting the object approach is to make the file look organized and reduce line count. But visual organization ≠ good architecture.

Just because "they're all states" doesn't mean they belong together.

This approach makes the state harder to:

Debug
Test
Maintain

What truly matters in code organization is making the logic explicit and resilient, not saving a few lines.

The road with useReducer:
When you start managing several related states, especially booleans like loading flags, form validations, request statuses, useReducer becomes a powerful alternative.

It allows you to group related states logically while keeping updates isolated.
A well-structured reducer makes state transitions explicit, predictable, and traceable.
dispatch and type bring a Redux-like structure, but lighter and scoped locally.
Independent updates won’t trigger unnecessary renders because state reactivity remains granular.

**But, how to use it?

Step 1: Define actions and initial state**

We create the available actions and the initial state, which contains two boolean flags: isLoading and isSubmitting.

Step 2: Create the reducer function
The reducer function takes the current state and an action, then returns the updated state based on the action type.

Step 3: Create the MiniLoader component using useReducer
Inside the component, we use useReducer by passing the reducer and initialState. We define two functions that simulate asynchronous operations and update the corresponding loading states.

To Infinity, And Beyond!

Reducers can be unit tested in isolation.
It’s easier to scale the state logic as your component grows.
You can add new actions without disrupting existing flow.

"In the crack of the eggs":
Visual organization ≠ good architecture. Replacing multiple useStates with a single object feels like an optimization, but it’s a dangerous abstraction that harms maintainability, performance, and clarity.

On the other hand, useReducer scales better, offers better control, and gives you a more predictable and reliable component structure.

If your component is juggling multiple flags or tightly related states, stop fighting useStates, embrace the power of useReducer.

It’s a small change that brings big benefits: cleaner, scalable, and more robust code.

#ReactJS #useState #useReducer #ReactHooks #CleanCode #FrontendTips #WebPerformance #CodeQuality #ReactBestPractices #JavaScript #DevTips #FrontendArchitecture #ScalableCode #MaintainableCode

New React 19 Hook: use()

Matheus Vieira do Nascimento — Mon, 06 Jan 2025 19:27:15 +0000

With use(), the way we handle asynchronous data in React components has been drastically simplified.

💡 Before vs. Now: Comparison with Examples

Before React 19
Handling asynchronous data required the use of useEffect and useState, leading to more verbose code:

With React 19 and the use() Hook
Now it's possible to handle Promises directly in the component body in a more declarative way:

By using use(), React pauses the component rendering until the Promise is resolved, directly integrating with the loading management of the Suspense API.

My Experience with AsyncThunk in Redux Toolkit

Matheus Vieira do Nascimento — Wed, 20 Nov 2024 04:29:09 +0000

Hey devs! I wanted to share something I’ve been using a lot at work that has made managing async calls in Redux much easier: the createAsyncThunk.

If, like me, you’ve struggled to keep async calls organized in Redux, here’s some good news: AsyncThunk simplifies it all in a super clean way.

Here’s a real example I used to fetch data with GraphQL:

Why do I love it?

Clean and organized: You can track the status of an async request (loading, success, or error) directly in the slice.
Less boilerplate: No need to manually write actions and reducers for async logic—it’s all handled automatically.
Easy maintenance: Everything lives in one place, making it simple to read and update when needed.

Since I started using createAsyncThunk, async calls in Redux have been so much smoother. If you haven’t tried it yet, I highly recommend it.

📢 Why I Use Git UIs in My Daily Work and What You Should Know About Them

Matheus Vieira do Nascimento — Fri, 01 Nov 2024 14:07:42 +0000

When it comes to development tools, version control is a crucial part of any project. Git, one of the most widely used tools for this, can be a bit intimidating at first. So many developers, especially with the daily rush, end up using graphical interfaces (Git UIs) to make the process easier.

💡Git Graph on VS Code:
For those of us using Visual Studio Code, the Git Graph extension is one of my favorites. It offers functionalities that greatly simplify working with Git repositories, such as:

Tree view visualization: You can clearly see all commits, branches, and merges on a graphical timeline, which is super helpful when trying to understand the change history in larger projects.
Quick branch control: With Git Graph, it’s easy to switch between branches, create new ones, merge, and view everything without leaving the editor.
Commit comparison: You can compare differences between specific commits, making it faster to understand changes between versions. This feature is a huge help for anyone who frequently reviews code.

Using tools like Git Graph significantly reduces the time and effort needed for common Git tasks. However, I don't recommend using Git UIs for those who are just starting to learn Git. Why? Simply because using the terminal is essential for a deep understanding of how Git works. Writing and executing commands manually in the terminal helps you grasp Git's functionality, version control concepts, and the processes behind each action.

I know it may feel harder at first, but the learning is much more solid. What I suggest is: practice with the terminal, learn the flow of commits, branches, merges, rebases, etc. Only after you build that foundation will a graphical interface make sense and truly be a helpful tool for your daily workflow—not just a crutch.

In summary, Git UIs can absolutely speed up your workflow, and Git Graph is one of the best options on VS Code. But if you're just starting out, my tip is: start with the terminal!

maxLength input type=number

Matheus Vieira do Nascimento — Fri, 16 Aug 2024 20:23:37 +0000

Have you ever needed to use a numeric input but couldn't limit the maximum number of characters?! I faced this recently and I'm sharing what helped me!

🔐 Developing a Custom OTP Input Component 🔐
Recently, I needed to create an OTP input component for a project where users had to enter a verification code sent via SMS or email. The challenge was to ensure that the input accepted only numbers and that each field allowed only a single digit.

Problem
The <input type="number"/> ignores the HTML "maxLength" property, making it necessary to use JavaScript to achieve this behavior. When we create an input of this type, the element automatically converts all non-numeric values into empty strings! After some research and experimentation, I came up with a solution that combines simplicity and efficiency.

📋Input code:



<input
  type="number"
  maxLength={1}
  inputMode="numeric" //Opens numeric keyboard on mobile
  onInput={(e) => {
    const target = e.target as HTMLInputElement;

    // Removes non-numeric characters
    target.value = target.value.replace(/\D/g, "");

    // Limits to one digit
    if (target.value.length > target.maxLength) {
      target.value = target.value.slice(0, target.maxLength);
    }
  }}
/>

💡How it works:

replace(/\D/g, ""): Removes any non-numeric characters, ensuring that only numbers are entered.
maxLength={1} e slice(0, target.maxLength): Limit the input to a single digit.

This solution was essential to create a clean and intuitive user experience, focusing on simplicity and efficiency in entering the OTP code.

But why handle non-numeric characters if the input type is number?
Surprisingly, the letter "e" is interpreted as a number, meaning if the user somehow entered "e", it would be accepted. So, even with type=number, it was necessary to add this regex.

😊 BONUS
If you've ever used a numeric input, you've probably encountered those annoying little arrows:

Here's the CSS to hide them:



input {
  &::-webkit-outer-spin-button,
  &::-webkit-inner-spin-button {
      -webkit-appearance: none;
      margin: 0;
  }
  -moz-appearance: textfield;
}

I'm always looking for new ways to optimize the user experience in a simple yet effective way. What do you think of this approach? Any suggestions or alternatives that you've used? Let's discuss! 💬