DEV Community: Sagiv ben giat

The New Bottleneck - When AI Writes Code Faster Than Humans Can Review It

Sagiv ben giat — Sat, 14 Mar 2026 13:32:41 +0000

The 10x Productivity Paradox

We're living through an incredible shift in software development. AI agents have made it absurdly easy to write code - close tech debt gaps, create multiple POC implementations, kill bugs, dramatically increase testing coverage, and ship new features at lightning speed. The promise of 10x velocity increase is real, and it's here.

But here's the uncomfortable truth: the bottleneck has shifted.

In the traditional software delivery cycle, writing code was often the slowest phase. Now? It's the fastest. The new bottleneck is code review. Humans simply can't review the enormous volume of code that AI agents can generate.

The "Keep PRs Small" Band-Aid

The obvious solution seems simple: stick to the good old standard of "keep pull requests small." Set limits on lines of code or number of files. Problem solved, right?

Not quite.

Sure, we can enforce small PRs and technically 'solve' the review bottleneck. But let's be honest - we're not solving the problem, we're ignoring innovation and pushing back on evolution.

If we can achieve a 10x increase in code generation, why not strive for a 10x increase in code review capacity?

If we keep delivering at the same pace while the world evolves around us, our competitors won't wait - and neither will our customers.

The Obvious Suspect: AI Reviewers

So what's the solution? Well, the obvious suspect is the AI agent itself, right? If an AI agent helped us produce 10x more code, it should help us review it at the same rate and volume.

But then comes that feeling. That awkward, uncomfortable feeling.

This code isn't really mine. I didn't write it. I barely reviewed it. How can I have confidence shipping it to production?

A Strange Thought: What If AI Code Is Just Another Dependency?

Lately, a strange thought has been popping into my mind: What if AI agents are dependencies?

Think about it. What if AI-generated code is just another third-party code? I'm positive that most of us don't review third-party code - dependencies that we install and use. If you think about it, most of the code we ship to production isn't ours. It's a third-party library we use, a dependency library, which also has dependencies, which have dependencies, and so on. You know that tree.

But here's the part we rarely stop to think about: the trust is recursive. The author of that library you trust? They also trust third-party code they didn't review. And the authors of those nested dependencies trust their own dependencies. Every node in that tree is trusting code that someone else wrote, someone else reviewed - or maybe no one reviewed at all. And we ship all of it to production.

So what's the difference between that and AI-generated code? In both cases, someone - or something - we don't know wrote the code, someone we don't know reviewed it, and in the case of open-source, someone we don't know even starred it on GitHub and we base our trust on that.

How We Make Peace With Third-Party Code

How do we reconcile our minds with third-party code integrated into our codebase? We actually do a lot more than we realize.

We vet before we adopt. We check how active the project is - when was the last commit? How fast do maintainers respond to issues? We look at community signals - stars, downloads, who else is using it. We check the license. We read the docs. We might even skim the source code of the critical parts.

We test. Unit tests, integration tests, end-to-end tests, manual QA. We write contract tests that verify the dependency behaves the way we expect it to.

We secure our supply chain. We run vulnerability scanners and dependency audits. We pin versions and use lock files so nothing changes underneath us without our knowledge. We monitor for known vulnerabilities in our dependency tree.

We set boundaries. We wrap third-party code behind interfaces and abstractions. We define contracts - what goes in, what comes out. We make sure we can swap a dependency out without rewriting half the codebase.

We monitor in production. We have observability - logs, metrics, alerts. We use staged rollouts and feature flags. We can roll back fast if something breaks.

What if AI-generated code is just another third-party dependency? What if we need the same trust mechanisms - vetting, testing, boundaries, security scanning, and monitoring?

The Rabbit Hole Deepens

The longer I think about this idea, the harder it is for me to counter-argue against it. My mind starts drifting to more questions - and the uncomfortable part is that none of them feel unanswerable.

Should there be a way to distinguish AI-generated code from human-written code in the codebase? How do I mark it, track it, set boundaries around it?
Do I need to see and read the code myself, or is it enough to define clear review rules and let AI agents review it for me?
How many AI agent reviewers do I need before I feel confident? Is one enough? Three?
If multiple AI agents review the same code and agree, is that more trustworthy than a single human reviewer who skimmed it?
Should we have different AI agents with different review focuses - one for security, one for performance, one for correctness?
What's the equivalent of "2 approvals required" in an AI-review world?

I don't have all the answers yet. But the thing that keeps pulling me deeper into this rabbit hole is that these questions feel like they have answers. They feel like problems we can solve - with tooling, with process, with experimentation. And if that's the case, if these concerns can be addressed with real solutions, then are we actually looking at a legitimate shift in how we think about code ownership and review?

The Uncomfortable Questions

Here's what keeps me up at night:

Trust without understanding: We trust libraries with millions of downloads that we've never read. Why is AI-generated code different? Is it because it's generated specifically for our codebase, making us feel more responsible for it?

The illusion of control: When we install a dependency, we accept that we don't control it. When AI generates code in our repository, we feel like we should control it. But should we?

And yet, the more I sit with these questions, the more I keep arriving at the same place:

Ownership doesn't mean authorship. Here's the reality - we own the code we ship to production, including third-party libraries. When there's a bug, the customer doesn't care if the faulty code is a third-party library or code written by me. Nor should I care about the distinction when fixing it. I should fix the bug - either by open-source contribution or in "user-land" - and make sure I catch it next time before the customer does. The same goes for AI-generated code. I didn't write it, I might not have reviewed every line, but if I use it, it's mine. Ownership is about responsibility, not authorship.

What This Means for the Future

If we accept this mental model - that AI-generated code is a dependency - it could change how we think about a lot of things. None of this is a recipe. It's a direction worth exploring.

Code review doesn't disappear - it evolves. Just as AI became our multiplier for writing code, it could become our multiplier for reviewing it. We'd still review. But the nature of human review might shift from line-by-line inspection to higher-level concerns, while AI agents handle the detailed implementation review.

Human review could shift toward contract review: Instead of reviewing every line ourselves, we'd focus on the contract: What should this code do? What are the edge cases? What are the performance requirements? AI reviewers could handle the implementation details - style, correctness, edge cases in the code itself.

Trust mechanisms could add layers of confidence: Tests, security scanning, pinned versions, and observability wouldn't replace review - they'd reinforce it. Together with AI-assisted review, they could form a safety net that's broader than any single human reviewer could provide.

Documentation might matter more than implementation: Understanding what the code does could become more important than understanding how it does it. Just like we read API docs for libraries instead of their source code.

Monitoring could close the loop: Instead of assuming correctness at merge time, we'd verify it continuously in production. Observability, alerts, and fast rollbacks would become first-class citizens in the delivery process - not afterthoughts.

If you take this idea far enough, it hints at something even more fundamental - we might be moving to a higher layer of abstraction altogether. English becomes the programming language. We write declarative specifications (the "what") instead of imperative code (the "how"). "Create a user authentication system with JWT tokens and rate limiting" becomes the new code. The AI figures out the implementation. This would require new forms of verification - tests that validate behavior rather than implementation, security scanning that runs automatically, monitoring that confirms correctness in production, and pipelines that validate the "what" was correctly translated into the "how."

The Next Bottleneck

Here's another brain teaser: What happens when both code generation and code review are 10x in volume?

Do we have enough product requests to keep us busy? Do we have enough problems to solve? Does the bottleneck shift to product discovery and requirement gathering?

But that's a topic for another post.

Where Do We Go From Here?

I don't have all the answers. This is a thought experiment, not a playbook. But if this idea resonates, here are some directions worth exploring:

What does trust infrastructure look like? Tests, security scanning, monitoring - the full chain, not just one link. If these are going to support our quality gate, how comprehensive, fast, and reliable do they need to be?
How should code review processes change? Maybe we need different review levels - contract review vs. implementation review. Maybe AI-generated code gets a different review process than human-written code. What would that look like for your team?
Where do boundaries make sense? Wrapping AI-generated code behind clear interfaces and abstractions could keep the blast radius small if you need to replace or rewrite it later.
What can we learn from AI reviewing AI? What happens when multiple AI agents review each other's code? What do they catch that humans miss - and what do they miss that humans catch?
What should we measure? How often does AI-generated code cause production issues compared to human-written code? We won't know unless we track it. Let data inform the conversation.
Is the discomfort useful? This feeling of unease might be healthy. It keeps us questioning and improving our processes rather than blindly adopting a new paradigm.

Final Thoughts

The AI era is forcing us to question fundamental assumptions about software development. The idea that AI-generated code might be just another dependency is uncomfortable, controversial, and possibly wrong.

But it's worth exploring. And if we do explore it, we don't have to go all-in immediately. In fact, we probably shouldn't.

Some areas of our codebase are critical and dangerous. Payment processing, authentication, security features, data privacy controls - maybe it's fine not to be 10x there. Maybe slower is safer, and safer is better. We can experiment with AI-generated and AI-reviewed code in less critical areas first. Internal tools, admin dashboards, test utilities, documentation. Build confidence, gather data, learn what works and what doesn't. Then, gradually expand as we develop better trust mechanisms, review processes, and confidence in the approach.

Not every part of your system needs to move at 10x speed. Sometimes, the right speed for critical infrastructure is the speed at which humans can thoroughly understand and validate every change.

But if we're going to unlock the true potential of AI in software development, we need to rethink not just how we write code, but how we review it, trust it, and build confidence around it.

The bottleneck has shifted. The question is: are we ready for a world where the code we ship isn't the code we wrote?

What do you think? Is AI-generated code a dependency? How are you handling code review in the age of AI? I'd love to hear your thoughts - find me at @sag1v.

Originally published on debuggr.io.

I write about software engineering, AI, and the things that keep bugging me about our industry. If this resonated with you, come visit debuggr.io for more.

Stop Asking AI for Answers - Start Shipping Fixes

Sagiv ben giat — Thu, 12 Mar 2026 22:49:57 +0000

Seven years ago I wrote about how answering Stack Overflow questions can boost your career.

The core idea was a shortcut. You could tackle real problems other developers were facing, learn fast, and leave a public trail that shows how you think.

A lot changed since then. Many of us do not start with Stack Overflow anymore. We start with AI.

So what is the new shortcut?

It is not "use AI to write code faster."

It is "use AI to enter real codebases faster."

The closest modern equivalent to answering Stack Overflow questions is contributing fixes to open source issues. AI is what finally makes this approachable at scale.

Why this was not approachable before AI

Open source was always the best training ground. Real code, real constraints, real users.

But the entry point was expensive. Not intellectually expensive, operationally expensive.

Before you can even touch the issue you came for, you often need to:

get the project running locally
deal with build tools, versions, and environment errors
find the real entry point in a large codebase
learn project structure and conventions
reproduce the issue reliably
run the right tests, or figure out how tests are organized

If you already have instincts for this, it is manageable. If you do not, it is noisy, slow, and demotivating. The setup steals the time and focus you wanted to spend on the actual problem.

Stack Overflow had a lower barrier. The problem was already isolated. You could focus on reasoning and writing the answer.

What AI unlocked

AI did not replace learning. It removed the worst friction at the beginning.

It acts like an onboarding buddy that never gets tired of your questions.

You can ask things like:

how to run the project locally
where the entry point for a feature probably lives
which files matter for a specific behavior
how to reproduce the bug step by step
which tests cover the relevant code path
what a module does in plain English
how to create a minimal repro or a failing test

That is the real unlock. You spend less time fighting setup and more time practicing the skill that actually compounds.

Now let me map the most important benefits from the old Stack Overflow post into the new world.

Gain experience with real world challenges

Then: answer a question and touch a real bug pattern in isolation.

Now: fix an issue in a real codebase and deal with real engineering constraints.

Even a small contribution forces you to practice things that tutorials tend to skip:

reproducing problems instead of guessing
reading existing code instead of starting from scratch
validating behavior, ideally with tests
keeping the fix small and safe
thinking about edge cases and compatibility

AI helps you get to the starting line. The work you do after that is what turns into experience.

Keep up with the race and stay ahead of the game

Open source is where change lands first. Frameworks evolve, tooling shifts, patterns come and go.

Working in real repos keeps you close to how things are built today, not only how they are explained in documentation.

AI makes it easier to jump between ecosystems without losing days to unfamiliar structure, which means more exposure per month.

Learning new things by mistake

This is the best kind of learning.

You show up to fix one issue and you end up learning about the build system, the test strategy, the release process, performance constraints, or some edge case you did not know existed.

In the past, this often felt like getting lost. Today, AI can guide you through the confusing noise without stealing the discovery.

Improve tech communication skills

Stack Overflow trained you to explain a solution to strangers. Open source trains you to work with a team.

You learn how to:

ask questions in a way that gets useful answers
write reproduction steps so others can verify
describe changes so reviewers do not have to guess
respond to feedback without ego
align with conventions you did not choose
collaborate asynchronously with people you have never met

AI can help draft messages, but the skill you build is clarity. The kind that makes you easy to work with.

Document your solutions

On Stack Overflow, the answer was the artifact.

With open source, your artifact is the trail:

a good issue comment that clarifies the problem
a minimal repro or failing test
a small fix
a PR description that explains what changed and why
sometimes a docs update

That trail becomes a portfolio. It shows how you validate, how you communicate, and how you reason inside real constraints.

Kindness, giving back to the community

A good fix does not help one person. It helps everyone who will hit the same issue later.

Small contributions count too. Docs improvements, clearer errors, better examples, tests that prevent regressions. These are quiet kindness moves that save strangers hours.

Points, credit, prestige

Stack Overflow had points. Open source has merged PRs, contributor history, and maintainers who recognize your name.

This signal is strong because it is hard to fake. It proves you can enter a codebase you do not own, understand it enough to change it safely, and collaborate like a teammate.

A simple weekly loop

If you want a repeatable habit:

Pick a repo you use, or something popular in your stack.
Find an issue labeled good first issue, documentation, or bug.
Use AI to help you run the project and locate entry points.
Reproduce the issue locally. If possible, turn it into a failing test.
Make a small fix.
Open a PR with a clear description, repro steps, and how to verify.

Do this consistently and you will level up in a way that is hard to get from courses, side projects, or even your day to day work.

Closing

The old shortcut still exists. It just moved.

In the past, answering Stack Overflow questions let you practice real world problems without entering real codebases.

Today, AI makes entering real codebases cheap enough that open source issues become the new training ground.

Originally published on debuggr.io.

I write about software engineering, AI, and the things that keep bugging me about our industry. If this resonated with you, come visit debuggr.io for more.

The Internet Is Getting Quieter - Who Will Feed the Next Generation of AI?

Sagiv ben giat — Thu, 12 Mar 2026 22:48:44 +0000

Here is the irony that keeps bothering me.

Stack Overflow helped train the AI models that are now making Stack Overflow irrelevant.

The models learned from millions of questions and answers, real developers hitting real walls and working through them publicly. Now those same models answer questions directly, traffic drops, fewer developers bother posting, and the ecosystem that fed the models quietly starves.

I do not see many people talking about this. Maybe I am missing something. But it feels like an underrated problem, and I keep coming back to it.

What is actually being lost

At first glance this looks like a platform problem. Stack Overflow loses users, Stack Overflow loses revenue. Sad for them, not our problem.

But dig one layer deeper and it is a knowledge problem.

When a developer hit a weird bug in 2015, they might have spent hours figuring it out, then posted the question and the solution publicly. That post became a permanent artifact. Other developers found it, upvoted it, added edge cases in the comments. The knowledge compounded over time in a place everyone could access.

Today, that same developer asks their AI assistant. Gets an answer. Moves on.

The solution evaporated. It lives in no one's chat history but theirs.

Multiply that by millions of developers, every day. That is not a Stack Overflow problem. That is a collective knowledge problem.

Why this matters for AI itself

Here is where it gets recursive.

Today's models were trained on the public internet. A large chunk of that training data was Stack Overflow, GitHub issues, blog posts, forum threads. People sharing what they figured out, openly, where crawlers could find it.

Now that flow is slowing. Novel solutions are being solved privately. The public record is not getting updated the same way it used to.

Future models will be trained on... what exactly?

The obvious answer is synthetic data. Models generating their own training data, or learning through code execution loops. And for verifiable things like "does this code run correctly" that works reasonably well.

But a lot of valuable knowledge is not verifiable that way. The "I tried approach X and here is why it failed" post. The architecture decision thread. The debugging session where someone walked through their reasoning out loud. That is the kind of signal that is hard to synthesize, because it came from genuine confusion followed by genuine discovery.

If that signal disappears from the public internet, future models lose something real.

The privatization problem

There is a related issue that is even less discussed.

Right now, when your team's best engineers solve a hard problem, that knowledge lives in a private Slack thread, an internal wiki, or an AI chat log that belongs to your company.

In the past, some of that knowledge would eventually surface publicly. A blog post. A Stack Overflow answer. A conference talk. Informal, slow, but it happened.

That pipeline is shrinking. The incentive to share publicly is weaker when you already have an AI assistant that answers you faster than any forum would. Knowledge is being privatized at scale, and it is not a conspiracy, it is just the path of least resistance.

The public knowledge commons is not being maintained the way it was.

One rough direction worth thinking about

I do not have a clean solution. But one idea has been rattling around in my head.

What if AI agents were first-class participants in a public knowledge platform?

Not just as consumers of knowledge, but as contributors. When an agent solves a novel problem, instead of that solution disappearing, it posts it publicly. The chain of thought, the approaches it tried, what worked and why. Other agents that encounter similar problems can find it, use it, and vote on whether it was actually useful.

A kind of Stack Overflow for agents.

The rough idea raises obvious questions immediately:

Who is the accountable human behind a post? Auth cannot be anonymous. An agent posting a solution needs to be traceable back to an operator or developer who registered it. The same way you are responsible for a third-party library you choose to install, you would be responsible for what your agent puts into the commons.

Where do the rules live? The natural answer today is an MCP server. The platform exposes itself as a tool. The schema, the posting rules, the voting API are all in the tool definition. The agent does not need to be pre-trained on the platform, it discovers it the same way it discovers any other capability.

When does the agent actually post? Probably not in the hot path of a task. More likely as an async step after the run completes, after the solution is verified, when there is enough context to decide whether what was found is genuinely novel and worth sharing.

None of this is a spec. It is a rough sketch of a direction.

The real unsolved piece

Even if the technical problems above are solvable, the harder problem is governance.

Who builds and maintains a public knowledge commons for agents? A company will monetize it and close it eventually. An open standard needs adoption before it has value, which is a classic chicken-and-egg problem.

Stack Overflow worked because there was a culture of sharing. Developers felt something when they posted a good answer. Reputation, contribution, paying it forward. Agents do not have culture. They need incentives built into the systems that run them.

That is the part I do not have a good answer to.

Where does this land

I keep coming back to this because the trajectory feels clear.

Models were trained on a public internet where people shared what they figured out. That internet is getting quieter. The knowledge is still being created, it is just being created privately, in systems designed for individual productivity rather than collective memory.

That might be fine for now. The models we have are already good. But what about the ones we train in five years, on data that increasingly reflects synthetic output and private interactions rather than genuine public problem-solving?

I do not think this is catastrophic. I do think it is underrated.

If you know of work being done here, I would genuinely love to hear about it. Reach me at @sag1v.

Originally published on debuggr.io.

I write about software engineering, AI, and the things that keep bugging me about our industry. If this resonated with you, come visit debuggr.io for more.

Bridging the Gap - How We Made AI Agents 10x Developers in Our Organization

Sagiv ben giat — Thu, 12 Mar 2026 22:10:51 +0000

The Problem: AI Agents Don't Know Your Organization

AI coding assistants have revolutionized how we write code. They can generate functions, debug errors, and suggest optimizations in seconds. The promise is clear: become a 10x developer with AI as your co-pilot.

But here's the reality check: the moment your AI agent needs to work with your organization's internal infrastructure, the magic breaks down.

Your AI agent doesn't know:

Which design system your team uses
How your CI/CD pipelines are structured
What internal libraries you have for logging, metrics, and tracing
Your organization's coding standards and conventions
How to manage your staging environments
Which services exist and how they interact
Your deployment workflows and requirements

Instead of a multiplier, you get a drag. Instead of a driver, you get a passenger asking for directions every few minutes.

This isn't a frontend problem. It's not specific to any one company. This is a universal challenge every organization faces when adopting AI development tools.

The Root Cause: Context is King

AI agents are incredibly powerful, but they're only as good as the context they have. When working with public libraries and frameworks, they have access to extensive training data, documentation, and examples. But your internal tools? Your organizational standards? That's a black box to them.

The traditional solution has been to manually paste documentation, explain architecture in chat, or let the AI fumble through trial and error. This works for simple tasks, but it doesn't scale. It certainly doesn't make you 10x more productive.

Our Solution: Teaching AI Agents About Our Organization

In our organization, we tackled this problem head-on for our frontend infrastructure. Our solution has three key components:

1. Comprehensive Documentation Layer

We created structured documentation that covers:

Architecture docs: How our multi-service portal architecture works, request flows, and system design
Conventions: Naming standards, coding patterns, and best practices
Workflows: Translation pipelines, deployment checklists, and contribution guidelines
Visual diagrams: Mermaid diagrams showing request flows, build pipelines, and deployment processes

This isn't just README files scattered across repositories. It's a curated, interconnected knowledge base designed specifically for AI consumption.

2. Living Project Catalog

We maintain a catalog of all our frontend infrastructure projects with rich metadata:

Project types (services, libraries, templates)
Technology stacks
npm package names
Internal dependencies
Documentation links
Ownership information

This gives AI agents a complete map of our ecosystem - what exists, how it's connected, and where to find more information.

3. MCP Server: The Bridge Between AI and Infrastructure

The magic happens through a Model Context Protocol (MCP) server - a standardized way for AI agents to access external tools and data sources.

Our MCP server provides AI agents with specialized tools:

Discovery Tools:

list_projects: Browse all available frontend infrastructure projects
get_project_metadata: Get detailed information about specific projects including dependencies, tech stack, and documentation links

Documentation Tools:

get_architecture_docs: Fetch architecture documentation, diagrams, conventions, and workflows
get_documentation: Access project-specific documentation and guides

Source Code Tools:

list_project_files: Explore repository structure and file organization
get_project_files: Fetch source code from any project (with proper authentication)

Scaffolding Tools:

clone_template: Get instructions to scaffold new services from approved templates

All of this happens securely through Okta authentication, ensuring that AI agents only access what developers are authorized to see.

How It Works in Practice

Here's a real-world scenario:

Developer: "Create a new frontend service that displays user analytics with charts"

Without MCP Server:

AI: I'll create a React app with Chart.js...
Developer: No, we use our internal design system
AI: Which design system?
Developer: Our component library
AI: How do I import it?
Developer: *pastes package name and import examples*
AI: How should I structure the service?
Developer: *explains our multi-service architecture*
AI: How do I deploy it?
Developer: *explains deployment pipeline, service registration, manifest files, etc.*

With MCP Server:

AI: Let me check your frontend infrastructure...
    [Calls list_projects to discover available tools]
    [Calls get_architecture_docs to understand the system]
    [Calls get_project_metadata to learn about the component library]
    [Calls clone_template to get the service template]

    I'll scaffold a new service using your standard template,
    integrate with your component library, and set up
    the deployment configuration following your conventions.

The AI agent autonomously discovers what it needs to know, follows organizational standards, and produces production-ready code that fits seamlessly into your infrastructure.

The Impact

With this approach, organizations can achieve:

Reduced onboarding time: New developers can start contributing faster because AI agents guide them through organizational standards
Consistent code quality: AI agents follow conventions automatically
Fewer production issues: AI agents know about critical deployment requirements that developers might miss
Faster feature development: Developers spend less time explaining context and more time building features

The Bigger Picture: Every Organization Needs This

Our implementation is specific to our frontend infrastructure, but the pattern is universal. Every organization with internal tools, platforms, and standards faces this challenge.

The Model Context Protocol provides a standardized way to solve it. Whether you're building:

Backend services with internal frameworks
Mobile apps with custom SDKs
Infrastructure with proprietary tools
Data pipelines with internal platforms

You need a way to teach AI agents about your organization's unique context.

Key Takeaways

AI agents are powerful, but context-blind: They need explicit access to your organizational knowledge
Documentation alone isn't enough: You need a structured, machine-readable way to expose information
MCP worked for us: Model Context Protocol provided a proven pattern for extending AI agents - it might work for you too, or you might find a different implementation that fits your needs
Security matters: Proper authentication ensures AI agents respect access controls
Start small, iterate: Begin with your most critical pain points and expand over time

Getting Started

If you're interested in building something similar for your organization, start by identifying real pain points:

Test with real tasks: Ask your AI agent to perform common tasks in your organization - "Create a new service", "Add authentication to this endpoint", "Set up monitoring for this component"
Identify missing knowledge: When the AI fails or produces incorrect code, note what organizational knowledge it's missing - Is it the deployment process? Your internal libraries? Coding conventions?
Add context manually first: Provide the missing information directly in the chat and verify the AI can complete the task successfully with that context
Gather 2-3 use cases: Repeat this process for different scenarios to understand the pattern of what knowledge AI agents need most
Build tools for those use cases: Once you have clear patterns, create MCP tools that provide that knowledge programmatically - start with tools that address your most common pain points
Validate with original tasks: Test that your tools actually help the AI agent solve the tasks from your use cases without manual intervention

This approach ensures you're building tools that solve real problems rather than creating infrastructure that might not get used.

The future of AI-assisted development isn't just about smarter models - it's about giving those models the right context to understand your organization. When you bridge that gap, AI agents truly become the 10x multiplier they promise to be.

Want to learn more about the Model Context Protocol? Check out modelcontextprotocol.io for the specification and examples.

Originally published on debuggr.io.

I write about software engineering, AI, and the things that keep bugging me about our industry. If this resonated with you, come visit debuggr.io for more.

React - setState is not a function

Sagiv ben giat — Sun, 15 Mar 2020 12:09:44 +0000

Originally posted on my personal blog debugger.io

If you are a react developer and using a class component, you probably faced this error at least once:

TypeError: this.setState is not a function

TL;DR - If you are not in the mode for reading or you just want the bottom line, then here it is

Prerequisite -

We are going to mention the this context quite a lot here, if you are not exactly sure on how this works, i strongly advice reading JavaScript - The "this" key word in depth first.
We are also going to touch a little bit on the prototype chain subject, if you are not exactly sure how it works or not sure how classes works under the hood, i strongly advice reading JavaScript - The prototype chain in depth.

The problem

In order to understand what are the possible solutions, lets first understand what is the exact issue here.

Consider this code block:

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  countUp() {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  }

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={this.countUp}>{count}</button>
      </div>
    );
  }
}

We have a component that manage a state with a counter property, we have a handler that is attach to the onClick of a <button> which will invoke the React.Component's setState method.

unfortunately, this won't work well. When the user click the button we will get an error:

TypeError: this.setState is not a function

We do use the extends React.Component which means we get access to all React.Component methods via this. So how come we can't invoke this.setState.

The real problem here, is that we "lost" the context of this inside that handler, or maybe not lost but its not pointing to where we think it should point.

What is the context of this in our case then?

Lets revisit our flow-chart from the JavaScript - The "this" key word in depth article:

Although there is no "event handlers" flow, we can place them under the "dot notation" or "object's member".

You can look at event handlers that are attached to DOM elements as if the function is a method inside the element’s object, in our case the button object. We can look at it as if we did button.click() or even button.countUp(). Note that this is not exactly whats going on under the hood, but this visualization of the invocation of the handler can help us with the formation of our “mental model” regarding the setting of this. You can read more about it on the MDN.

So what is this pointing to in our case? Lets walk through the flow:

Is countUp an arrow function? - No.
Was countUp called with new? - No.
Was countUp called with call / apply / bind? - No.
Was countUp called as an object method? - Yes (sort of), in our case the actual button is left to the dot, hence this is pointing to the button element.

This is why we have an error, because the button element does not have any setState method on it.

Possible solutions

#1 bind

One possible solution is to use bind and return a new function with an explicit this reference:

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  countUp() {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  }

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={this.countUp.bind(this)}>{count}</button>
      </div>
    );
  }
}

This works great and we don't get any errors, although we are creating and passing a new function on each render cycle which may have performance implications (or might not).

We can use bind in the constructor which will run only once for the entire life-time of the component.

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
    this.countUp = this.countUp.bind(this);
  }

  countUp() {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  }

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={this.countUp}>{count}</button>
      </div>
    );
  }
}

This way, we are "overriding" the class method with an instance method, meaning we are not using the countUp method attached to the App.prototype but creating a method directly on the instance returned by App.

If you are not sure you fully understand how the prototype chain works under the hood, or not sure how classes works under the hood, i strongly recommend reading the JavaScript - The prototype chain in depth article

So why is using bind works for us? Lets walk through the flow again:

Is countUp an arrow function? - No.
Was countUp called with new? - No.
Was countUp called with call / apply / bind? - Yes.

Meaning, our this will reference whatever we pass to bind, which is the class instance.

#2 Arrow function

Instead of manually dealing with the this reference and passing it via bind, we can let the language / engine do it for us.

When using arrow functions, the engine will not "mutate" the this reference and will leave it as is, meaning whatever the this is pointing to at the wrapping execution context.

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  countUp() {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  }

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={() => this.countUp()}>{count}</button>
      </div>
    );
  }
}

We are passing an inline arrow function and invoking this.countUp, this way the engine will not "mutate" our this reference thus it won't point to the button element, our function is called with a dot notation.

So lets walk through the flow again:

Is countUp an arrow function? - No.
Was countUp called with new? - No.
Was countUp called with call / apply / bind? - No.
Was countUp called as an object method? - Yes, this is the object left to the dot - The auto created object inside App in this case (the instance).

While this works great, we are again passing a new function on each render cycle, although it won't create any issues most of the time, you might want to create this function once. We can do that with class fields - Note that at the time this article was written, class fields are a proposal on stage 3.

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  countUp = () => {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  }

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={this.countUp}>{count}</button>
      </div>
    );
  }
}

And if we are using class fields, why not remove the constructor and just declare the state as a class field?

class App extends React.Component {
  state = { count: 0 };

  countUp = () => {
    this.setState(currentState => {
      return { count: currentState.count + 1 };
    });
  };

  render() {
    const { count } = this.state;
    return (
      <div>
        <button onClick={this.countUp}>{count}</button>
      </div>
    );
  }
}

Now back to our this, why does it work with arrow functions? Lets walk through the flow again:

Is countUp an arrow function? - Yes. So whatever the this is in the wrapping context, which is the class instance.

Wrapping up

Make sure you don't "lose" the context of this in your handlers, either explicit pass it with bind (inline or override in constructor) or use an arrow function (inline or class field) that won't mutate and change the reference of this when it gets called.

I hope it was informative and helpful, if you have any further clarifications or corrections, feel free to comment or DM me on twitter (@sag1v). 🤓

For more articles you can visit debuggr.io

React - Cannot read property 'map' of undefined

Sagiv ben giat — Sat, 14 Mar 2020 20:35:52 +0000

Originally posted on my personal blog debugger.io

If you are a react developer, there is a good chance that you faced this error couple of times:

TypeError: Cannot read property 'map' of undefined

TL;DR - If you are not in the mode for reading or you just want the bottom line, then here it is

The problem

In order to understand what are the possible solutions, lets first understand what is the exact issue here.

Consider this code block:

// Just a data fetching function
const fetchURL = "https://jsonplaceholder.typicode.com/todos/";
const getItems = () => fetch(fetchURL).then(res => res.json());

function App() {
  const [items, setItems] = useState();

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  return (
    <div>
      {items.map(item => (
        <div key={item.id}>{item.title}</div>
      ))}
    </div>
  );
}

We have a component that manage a state of items, it also have an effect which inside it we run an asynchronous operation - getItems, which will return us the data we need from the server, then we call setItems with the received data as items.
This component also renders the items - it iterate over it with .map and returning a react element for each item.

But we wont see anything on the screen, well except the error:

TypeError: Cannot read property 'map' of undefined

What's going on here?

We do have an items variable:

const [items, setItems] = useState();

And we did populate it with our data returned from the server:

useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

Well lets examine how the react flow looks like in our example:

React renders (invoking) our component.
React "see" the useState call and return us [undefined, fn].
React evaluate our return statement, when it hits the items.map(...) line its actually running undefined.map(...) which is obviously an error in JavaScript.

What about our useEffect call though?

React will run all effects after the render is committed to the screen, which means we can't avoid a first render without our data.

Possible solutions

#1 Initial value

One possible solution is to give your variable a default initial value, with useState it would look like that:

const [items, setItems] = useState([]);

This means that when react runs our useState([]) call, it will return us with

[[], fn]

Which means that in the first render of our component, react will "see" our items as an empty array, so instead of running undefined.map(...) like before, it will run [].map(...).

#2 Conditional rendering

Another possible solution is to conditionally render the items, meaning if we have the items then render them, else don't render (or render something else).

When working with JSX we can't just throw some if else statements inside our tree:

// ⚠️ wont work!!
export default function App() {
  // ....
  return (
    <div>
      {
        if(items){
          items.map(item => (
            <div key={item.id}>{item.title}</div>
          ))
        }
      }
    </div>
  );
}

But instead we can create a variable outside our tree and populate it conditionally:

Note that we removed the initial array for items.

function App() {
  const [items, setItems] = useState();

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  let itemsToRender;
  if (items) {
    itemsToRender = items.map(item => {
      return <div key={item.id}>{item.title}</div>;
    });
  }

  return <div>{itemsToRender}</div>;
}

The undefined or null values are ignored inside the context of JSX so its safe to pass it on for the first render.

We could also use an else statement if we want to render something else like a spinner or some text:

function App() {
  const [items, setItems] = useState();

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  let itemsToRender;
  if (items) {
    itemsToRender = items.map(item => {
      return <div key={item.id}>{item.title}</div>;
    });
  } else {
    itemsToRender = "Loading...";
  }

  return <div>{itemsToRender}</div>;
}

#2.5 Inline conditional rendering

Another option to conditionally render something in react, is to use the && logical operator:

function App() {
  const [items, setItems] = useState();

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  return (
    <div>
      {items && items.map(item => {
          return <div key={item.id}>{item.title}</div>;
        })}
    </div>
  );
}

Why it works? The react docs explains it well:

It works because in JavaScript, true && expression always evaluates to expression, and false && expression always evaluates to false.
Therefore, if the condition is true, the element right after && will appear in the output. If it is false, React will ignore and skip it.

We can also use the conditional operator condition ? true : false if we want to render the Loading... text:

function App() {
  const [items, setItems] = useState();

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  return (
    <div>
      {items
        ? items.map(item => {
            return <div key={item.id}>{item.title}</div>;
          })
        : "Loading..."}
    </div>
  );
}

We can also mix both solutions, i.e: initial value with conditional rendering:

function App() {
  const [items, setItems] = useState([]);

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  return (
    <div>
      {items && items.length > 0
        ? items.map(item => {
            return <div key={item.id}>{item.title}</div>;
          })
        : "Loading..."}
    </div>
  );
}

Though keep in mind, whenever conditions become too complex, it might be a signal for us to extract that logic to a component:

function List({ items, fallback }) {
  if (!items || items.length === 0) {
    return fallback;
  } else {
    return items.map(item => {
      return <div key={item.id}>{item.title}</div>;
    });
  }
}

function App() {
  const [items, setItems] = useState([]);

  useEffect(() => {
    getItems().then(data => setItems(data));
  }, []);

  return (
    <div>
      <List items={items} fallback={"Loading..."} />
    </div>
  );
}

Wrapping up

When we get such an error, we are probably getting the value in an asynchronous way. We should provide an initial value for our variable or conditionally render it or both. If our condition become too complex, it might be a good time to extract the logic to a component.

Hope you found this article helpful, if you have a different approach or any suggestions i would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

JavaScript == VS === The truth

Sagiv ben giat — Wed, 27 Nov 2019 16:50:30 +0000

The truth behind the double and triple equal in JavaScript

Originally posted in debuggr.io

Some of the most frequently-asked interview questions of Front-End are about Equality comparisons and sameness in JavaScript (ECMAScript).

And the queen of these questions is:

What is the difference between the “double equals” and the “triple equals”?

Well, we all know the answer for that. The triple equal checks for types while the double equal isn’t.

That could be a short and nice answer for this question but unfortunately it is FALSE.

As per the specs, 7.2.14 Abstract Equality Comparison you can clearly see at the first check:

If Type(x) is the same as Type(y), then
Return the result of performing Strict Equality Comparison x === y.

Well there we have it, the “double equal” should check the type in both sides of the operator and if they are the same, it will delegate the rest of the work to the “triple equal” (Strict Equality Comparison).

Ok then, is the “triple equal” checking for types then?

YUP! we can see it on the first line:

If Type(x) is different from Type(y), return false.

Ouch, so what is the difference then?

The right answer to this question is that the “double equal” allows type coercion while the “triple equal” won’t allow it.

The “Double equal” a.k.a “Abstract Equality” or “Loose equality” will use every trick in the ECMAScript specifications book to coerce a type conversion in order to perform an equality comparison:

The “Triple equal” a.k.a “Strict equality” will immediately return false if the two sides are not of the same type:

*Bonus tip.

What will happen if we will run this block of code:

var x = 2;

if(x == true){
  console.log('x is truthy!');
}

Nothing is printed to the console.

But we know that 2 is not a “falsy” value, so it should be loosely equal to true, Should it?

OK, maybe we are way off and 2 is a “Falsy” value:

var x = 2;

if(x == false){
  console.log('x is falsy!');
}

Nothing again? 😲

How is it possible that a value with a type of Number is not truty or falsy?

Lets revisit the spec and notice these 2 interesting rules in the “Abstract Equality” section:

If Type(x) is Boolean, return the result of the comparison ! ToNumber(x) == y.
If Type(y) is Boolean, return the result of the comparison x == ! ToNumber(y).

You see, the specs says that if one of the sides is of type Boolean, the engine should perform the Abstract ToNumber on it, but it doesn’t say that the engine should do anything to the other side’s type.

So basically this is how it coerce:

false becomes 0
true becomes 1
x is still 2

Hence none of our conditions is fulfilled => 2 != 0 && 2 != 1.

But what if we just want to check that (x) holds a “Truthy” value? we could just pass it to an if:

var x = 2;

if(x){
  console.log('x is truthy!');
}
// x is truthy!

Success!

Take Away

Never ever perform a “loosely” comparison (double equal) when one side is an explicit Boolean type.

Recap

Both the “double equal” and “triple equal” perform a type check, while the former allows a type coercion and the latter doesn’t.
Never use a “double equal” when you want to explicit compare against a Boolean.

Hope you found this article helpful, if you have something to add or any suggestions or feedbacks I would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

JavaScript - Closure in depth

Sagiv ben giat — Sat, 23 Nov 2019 15:17:12 +0000

Learn the concept of closure in JavaScript

Originally posted at my personal blog debuggr.io

In this article we will learn about the concept of closures in JavaScript, we will see how functions can be stateful with persistent data across multiple executions. We will also explore some of the popular use cases of closure and different approaches for using them.

Lets start with a quote from MDN:

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

If you ask me, i would say that closures enables us to create stateful functions.

Stateful functions

Stateful functions are functions that can "remember" data from previous executions. For example lets create a function that "remembers" and count how many times it got executed, each time that we will invoke it, it will log the number of times it got executed.

To do that, we will need some kind of a counter variable that will hold the current number of executions and will get incremented every time we invoke the function, the challenge here is to decide on where to put this variable.

Lets explore our first approach:

function counter(){
  let numOfExecutions = 0;
  numOfExecutions++;
  console.log(numOfExecutions);
}

counter() // 1
counter() // 1

Obviously this won't work well, because we are re-creating the numOfExecutions variable every time we invoke counter().

Execution context

Every time we invoke a function, a new execution context is created, and each execution context has it's own "Variable Environment" or "scope" if you will. This local variable environment is holding all arguments that got passed to it and all declarations made inside the body of the function, in our case the numOfExecutions variable. When the function is "done", e.g with a return statement or there are no more lines of code to execute, the engine will mark it to be garbage collected, meaning it's entire environment will get disposed.

This is the reason our code above doesn't work well, every time we invoke counter we create a new execution context with a new declaration of the numOfExecutions variable and incrementing it to the value of 1.

Global execution context

When we start our program, the engine will create a global execution context for us, its not different from the execution context we create when we invoke a function. It also has a "Variable Environment" just like any other execution context, the difference is that the global execution context will never "die" (as long as our program is running of course), hence it's variable environment won't get disposed by the garbage collector.

So knowing that, we can maybe store our numOfExecutions in the global variable environment, this way we know it won't get re-created each time we invoke counter.

let numOfExecutions = 0;

function counter(){
  numOfExecutions++;
  console.log(numOfExecutions);
}

counter() // 1
counter() // 2

This works as we expect, we get the correct number of invocations, but you probably already know that storing variables on the global environment is considered as bad practice. For example see what happens if another function wants to use the exact same variable:

let numOfExecutions = 0;

function counter() {
  numOfExecutions++;
  console.log(numOfExecutions);
}

function someFunc() {
  numOfExecutions = 100;
}

someFunc()
counter() // 101
counter() // 102

As you can see we get some wrong numbers in here.

Another issue with this approach is that we can't run more than 1 instance of counter.

Lexical Scope

Lexical Scope is basically a fancy way of saying "Static Scope", meaning we know at creation time what is the scope of our function.

Read this carefully:

WHERE you define your function, determines what variables the function have access to WHEN it gets called.

In other words, it doesn't matter where and how you invoke the function, its all about where did it got declared.

But how do we declare a function in one place, and invoke it in another place? Well, we can create a function within a function and return it:

function createFunc() {
  function newFunc(){

  }

  return newFunc;
}

const myFunc = createFunc();
myFunc()

It may seem useless, but lets explore the execution phase of our program:

We declare a new function with the createFunc label in the global variable environment.
We declare a new variable myFunc in the global variable environment which it's value will be the returned value from the execution of createFunc.
We invoke the createFunc function.
A new execution context is created (with a local variable environment).
We declare a function and giving it a label of newFunc (stored in the local variable environment of createFunc).
We return newFunc.
The returned value from createFunc is stored as the value of myFunc in the global variable environment.
The variable environment of createFunc is marked for disposal (meaning the newFunc variable will not exist).
We invoke myFunc.

Note that when we return the function newFunc, we return the actual function definition, not the label.

OK, so what can we do with this approach?

It turns out, that when we return a function, we are not only returning our function definition but we also return it's entire lexical environment. I.e, if we had some variable declared in the same context (or outer contexts), our returned function would close over them, and keep a reference to them.

Lets see that in action with our counter example:

function createCounter() {
  // creating a wrapping execution context
  // so we won't pollute the global environment
  let numOfExecutions = 0;

  // creating and returning an inner function
  // that closes over the lexical environment
  function counter() {
    numOfExecutions++;
    console.log(numOfExecutions);
  }

  return counter;
}

const counter = createCounter();

counter() // 1
counter() // 2

As you can see, we are creating a wrapper execution context (createCounter) to store our numOfExecutions variable and we are returning the counter function. This way, every time we invoke counter it has access to the numOfExecutions variable. The fact that we are not re-running createCounter and only run counter let us persist numOfExecutions across executions of counter, thus allow counter to be stateful, meaning we can share data with multiple executions of this function.

If we debug counter's execution we can see in the developer-tools that numOfExecutions is not stored in the local variable environment of counter but in it's "Closure" scope, (refers to as [[Scope]] in the spec).

But what if we wanted to return an object and not a function?

No problem, it will still work as expected:

function createCounter() {
  let count = 0;

  function increment() {
    count++;
    return count;
  }

  function decrement() {
    count--;
    return count;
  }

  function reset() {
    count = 0;
  }

  function log() {
    console.log(count)
  }

  const counterObj = {
    increment,
    decrement,
    reset,
    log
  }

  return counterObj;
}

const counter = createCounter();

counter.increment()
counter.increment()
counter.increment()

counter.log() // 3

☝️ By the way, this pattern is usually called the "Module Pattern".

As you can see, it doesn't matter what we are returning, it doesn't matter where or when we are calling the functions, the only thing matters is where did we defined our functions:

WHERE you define your function, determines what variables the function have access to WHEN it gets called.

Another bonus we get from returning a function or an object with functions is that we can create multiple instances of counter, each will be stateful and share data across executions but won't conflict between other instances:

function createCounter() {
  let numOfExecutions = 0;

  function counter() {
    numOfExecutions++;
    console.log(numOfExecutions);
  }

  return counter;
}

const counter1 = createCounter();
const counter2 = createCounter();

counter1() // 1
counter1() // 2

counter2() // 1
counter2() // 2

As you can see, counter1 and counter2 are both stateful but are not conflicting with each others data, something we couldn't do with a global variable.

Optimizations

Every returned function is closing over the ENTIRE lexical scope, meaning the entire lexical scope won't be garbage collected 🤔. This seems like a waste of memory and even a potential memory leak bug, should we re-consider the use of closures every time we need staeful functions?

Well, no. Most if not all browsers are optimizing this mechanism, meaning that in most cases only the variables that your function is actually using will be attached to the function's [[scope]]. Why in most cases and not all cases? Because in some cases the browser is unable to determine what variables the function is using, such as in case of using eval. Obviously this is the smallest concern of using eval, it is safer to use Function constructor instead.

Wrapping up

We learned about how "Closure" works under the hood, with a link to the surrounding lexical context. We saw that scope wise, it doesn't matter when or where we are running our functions but where we are defining them, in other words: Lexical (static) binding. When we return a function, we actually returning not only the function but attach to it the entire lexical variable environment of all surrounding contexts (which browsers optimize and attach only referenced variables). This gives us the ability to create stateful functions with shared data across executions, it also allows us to create "private" variables that our global execution context doesn't have access to.

Hope you found this article helpful, if you have something to add or any suggestions or feedbacks I would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

JavaScript - The prototype chain in depth

Sagiv ben giat — Sat, 09 Nov 2019 11:30:04 +0000

Learn the concept of inheritance with the prototype chain

Originally posted at my personal blog debuggr.io

In this article we will learn about JavaScript's prototype chain. We will see how objects connect to other objects and how we can implement "inheritance" and relationships between these objects.

Our Goal

As developers, our main task when we write code is usually to manipulate data. We get the data and store it some where, then we run functionality on that data.
Wouldn't it be nice to have the functionality and the relevant data bundled together on the same place? this would make it a lot easier for us.

Imagine a Player object:

{
  userName: 'sag1v',
  score: '700'
}

What if we want to run functionality on that object, like changing the score. Where would we put a setScore method?

Objects

when we want to store related data we usually use objects, we use it like a box and we put inside it relevant peices.
Before we dive in, lets first understand what an Object is and explore some of the ways we can create objects.

Object Literal

const player1 = {
  userName: 'sag1v',
  score: '700',
  setScore(newScore){
    player1.score = newScore;
  }
}

Objects with literal notation (or "Object initializer") are an expression, each object initializer results in a new object being created whenever the statement in which it appears is executed.

We can also create or access the object's properties with a dot notation or bracket notations:

const player1 = {
  name: 'Sagiv',
}

player1.userName = 'sag1v';
player1['score'] = 700;
player1.setScore = function(newScore) {
  player1.score = newScore;
}

Object.create

Another option to create an Object is using the Object.create method:

const player1 = Object.create(null)
player1.userName = 'sag1v';
player1['score'] = 700;
player1.setScore = function(newScore) {
  player1.score = newScore;
}

Object.create will always return a new empty object, but we will get a bonus feature if we pass a different object to it. We will get back to it later on.

Automating

Obviously we wouldn't want to create these object by hand every time, we might want to automate this operation. So lets create a function that will create a Player object for us.

Factory Functions

function createPlayer(userName, score) {
  const newPlayer = {
    userName,
    score,
    setScore(newScore) {
      newPlayer.score = newScore;
    }
  }
  return newPlayer;
}

const player1 = createPlayer('sag1v', 700);

This pattern is usually referred to as "Factory Functions", as in sort of a conveyor belt in a factory that outputs objects, we pass in the relevant arguments and get back the Object we need.

what happens if we run this function twice?

function createPlayer(userName, score) {
  const newPlayer = {
    userName,
    score,
    setScore(newScore) {
      newPlayer.score = newScore;
    }
  }
  return newPlayer;
}

const player1 = createPlayer('sag1v', 700);
const player2 = createPlayer('sarah', 900);

we will get 2 objects with this shape:

{
  userName: 'sag1v',
  score: 700,
  setScore: ƒ
}

{
  userName: 'sarah',
  score: 900,
  setScore: ƒ
}

Did you notice some duplications? Our setScore is stored for each instance, this is breaking the D.R.Y (Don't Repeat Yourself) principle.

What if we could store it somewhere else, once, and still be able to access it via the object instance: player1.setScore(1000)?

OLOO - Objects Linked To Other Objects

Lets get back to Object.create, we said that it will always create an empty object but we will get a bonus feature if we pass an object to it.

const playerFunctions = {
  setScore(newScore) {
    this.score = newScore;
  }
}

function createPlayer(userName, score) {
  const newPlayer = Object.create(playerFunctions);
  newPlayer.userName = userName;
  newPlayer.score = score;
  return newPlayer;
}

const player1 = createPlayer('sag1v', 700);
const player2 = createPlayer('sarah', 900);

This code works exactly like our previous code with one important difference, our new object instance doesn't hold the setScore method, it has a link to it in playerFunctions.

It turns out, that ALL objects in javascript have a special hidden property called __proto__ (pronounced "dunder proto"), and if that property is pointing to an object then the engine will treat this object's properties as if they were on the instance itself. In other words, every object can link to another object via the __proto__ property and access it's properties like they were it's own.

️️⚠️ Note

Don't confuse __proto__ with the prototype property, prototype is a property that only exists on functions. __proto__ on the other hand is a property that only exists on objects. To make it more confusing, The __proto__ property is called [[Prototype]] in the EcmaScript specifications.

We will comeback to that later on 🤔

Lets see an example with our code for a better visualization:

const playerFunctions = {
  setScore(newScore) {
    this.score = newScore;
  }
}

function createPlayer(userName, score) {
  const newPlayer = Object.create(playerFunctions);
  newPlayer.userName = userName;
  newPlayer.score = score;
  return newPlayer;
}

const player1 = createPlayer('sag1v', 700);
const player2 = createPlayer('sarah', 900);

console.log(player1)
console.log(player2)

This will output:

player1: {
  userName: 'sag1v',
  score: 700,
  __proto__: playerFunctions
}

player2: {
  userName: 'sarah',
  score: 900,
  __proto__: playerFunctions
}

Which means, both player1 and player2 have access to the properties of playerFunctions, meaning they both can run setScore:

player1.setScore(1000);
player2.setScore(2000);

We achieved our goal here, we have objects with data and functionality attached to them and we didn't break the D.R.Y principle.

But this seems like a lot of effort to put just for creating linked objects:

We need to create the object.
We need to create a different object that holds our functionality.
We must use Object.create to link the __proto__ property to the functionality object.
We need to populate the new object with properties.
We need to return the new object.

What if some of these tasks could be done for us?

The `new` operator - A.K.A Constructor function

In the previous example we saw that we have some "tasks" to do in order to create our linked object inside the factory function. JavaScript can do some of these tasks for us if we just use the new operator with a function invocation.

But before we see that in action, let's make sure we are on the same page regarding what a function is.

What is a function really?

function double(num) {
    return num * 2;
}

double.someProp = 'Hi there!';

double(5); // 10
double.someProp // Hi there!

double.prototype // {}

We all know what a function is right? We can declare it, then invoke it with parentheses (). But looking at the code above, we can also read or create properties on it, exactly like we can do with objects. So my conclusion here is that functions in JavaScript are not just functions, they are sort of a "function & object combination". Basically every function can be invoked AND can be treated like an object.

The prototype property

It turns out, that all functions (with the exception of arrow functions) have a .prototype property on them.

Yeah, here is the warning again:

Not __proto__ or [[Prototype]], but prototype.

Now lets get back to the new operator.

Invoking with the `new` operator

This is how our function might look like with the new operator:

⚠️ If you are not 100% sure you understand how the this key word works, you might want to read JavaScript - The "this" key word in depth

function Player(userName, score){
  this.userName = userName;
  this.score = score;
}

Player.prototype.setScore = function(newScore){
  this.score = newScore;
}

const player1 = new Player('sag1v', 700);
const player2 = new Player('sarah', 900);

console.log(player1)
console.log(player2)

And this is the output:

Player {
  userName: "sag1v",
  score: 700,
  __proto__: Player.prototype
}

Player {
  userName: "sarah",
  score: 900,
  __proto__: Player.prototype
}

Lets walk through that code (execution phase)

We are executing the Player function with the new operator, note that i changed the name of the function from createPlayer to Player, only because this is a convention among developers. This is a way to signal to the consumer of the Player function that this is a "Constructor Function" and should be invoked with the new operator.

When we invoke a function with the new operator, JavaScript will do 4 things for us:

It will create a new Object.
It will assign the new Object to the this context.
It will linked the __proto__ property of that new object to the prototype property of the function. Player.prototype in our case.
It will return this new object, unless you return a different object.

If we would write the automated steps done by JavaScript it might look like the following snippet:

function Player(userName, score){
  this = {} // ⚠️ done by JavaScript
  this.__proto__ = Player.prototype // ⚠️ done by JavaScript

  this.userName = userName;
  this.score = score;

  return this // ⚠️ done by JavaScript
}

Lets look at step #3:

It will linked the __proto__ property of that new object to the prototype property of the function...

Meaning we can put any methods on Player.prototype and they will be available to our newly created object.

And this is exactly what we did:

Player.prototype.setScore = function(newScore){
  this.score = newScore;
}

So this is how we can create objects linked to other objects with the Constructor functions.

By the way, if we didn't use the new operator, JavaScript wouldn't do these tasks for us, we would just end up mutating or creating some properties on the this context. Remember this option, we will use this trick when we will do sub-classing.

There are ways to make sure the function was called with the new operator:

function Player(username, score){

  if(!(this instanceof Player)){
    throw new Error('Player must be called with new')
  }

  // ES2015 syntax
  if(!new.target){
    throw new Error('Player must be called with new')
  }
}

Again, for an in depth explanation about the this key word you can read JavaScript - The "this" key word in depth.

Class

If you don't like to write factory functions by hand or you don't like the constructor function syntax or manually checking if the function was called with the new operator, JavaScript also provides a class (since ES2015). Keep in mind though, that classes are mostly a syntactic sugar over functions and they are very different from the traditional classes in other languages, we are still using a "prototypal inheritance".

A quote from MDN:

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

Lets convert our "constructor function" to a class step by step:

Declare a class

We use the class key word and name our class the same way we named our constructor function from the previous section.

class Player {

}

Create a constructor

We will take the constructor function's body from the previous section and create a constructor method for our class with it:

class Player {
  constructor(userName, score) {
    this.userName = userName;
    this.score = score;
  }
}

Add methods to the class

Every method we want to attach to the Player.prototype can be simply declared as a class method:

class Player {
  constructor(userName, score) {
    this.userName = userName;
    this.score = score;
  }

  setScore(newScore) {
    this.score = newScore;
  }
}

Now the entire code

class Player {
  constructor(userName, score) {
    this.userName = userName;
    this.score = score;
  }

  setScore(newScore) {
    this.score = newScore;
  }
}

const player1 = new Player('sag1v', 700);
const player2 = new Player('sarah', 900);

console.log(player1)
console.log(player2)

When we run the code, we get the same output as before:

Player {
  userName: "sag1v",
  score: 700,
  __proto__: Player.prototype
}

Player {
  userName: "sarah",
  score: 900,
  __proto__: Player.prototype
}

As you can see, class works and behave the same as a function with a prototype chain, its just a different syntax. You also get a built-in check that the class function was invoked with the new operator.

Sub-Classing - A.K.A Inheritance

What if we wanted a special kind of Player, maybe a paid user Player who has unlocked features that a regular Player doesn't have, such as the ability to change the user-name.

So lets see what our goal here:

We want that a regular player will have a userName, a score and a setScore method.
We also want a paid user player that will have all the things a regular player has + a setUserName method, but obviously we don't want the regular player to have this ability.

Before we dive into it, lets visualize a chain of linked objects:

Consider the code below:

function double(num){
    return num * 2;
}

double.toString() // where is this method coming from?

Function.prototype // {toString: f, call: f, bind: f}

double.hasOwnProperty('name') // where is this method coming from?

Function.prototype.__proto__ // -> Object.prototype {hasOwnProperty: f}

We know that if a property is not directly on the object, the engine will look for this property on the linked object (if exists) via the __proto__ property. But what happens if the property we are looking for is not there as well? Well as we previously learned, all objects have a __proto__ property, so the engine will check the next linked object via the __proto__ property, and if the property we are looking for is not there? well i think you get it, the engine will keep going up the chain via the __proto__ property until it hits a dead end, i.e a null reference, which is basically the Object.prototype.__proto__.

So if we step through the code example:

double.toString()

double has no toString method ✖️.
Go through double.__proto__
double.__proto__ is pointing to Function.prototype which is an object that contains the toString method. Check ✔️

double.hasOwnProperty('name')

double has no hasOwnProperty method ✖️.
Go through double.__proto__
double.__proto__ is pointing to Function.prototype.
Function.prototype has no hasOwnProperty method ✖️.
Go through Function.prototype.__proto__.
Function.prototype.__proto__ is pointing to Object.prototype.
Object.prototype is an object that contains the hasOwnProperty method. Check ✔️

Here is a small animated gif to demonstrate the process:

Now back to our task of creating a paid user entity. We will go all the way again, we will implement this feature with the "OLOO pattern", "Constructor Functions" pattern and with classes. This way we will see the tradeoffs for each pattern and feature.

So lets dive in to sub-classing. 💪

OLOO - Sub Classing

This is the implementation of our task with the OLOO and factory function pattern:

const playerFunctions = {
  setScore(newScore) {
    this.score = newScore;
  }
}

function createPlayer(userName, score) {
  const newPlayer = Object.create(playerFunctions);
  newPlayer.userName = userName;
  newPlayer.score = score;
  return newPlayer;
}

const paidPlayerFunctions = {
  setUserName(newName) {
    this.userName = newName;
  }
}

// link paidPlayerFunctions object to createPlayer object
Object.setPrototypeOf(paidPlayerFunctions, playerFunctions);

function createPaidPlayer(userName, score, balance) {
  const paidPlayer = createPlayer(name, score);
  // we need to change the pointer here
  Object.setPrototypeOf(paidPlayer, paidPlayerFunctions);
  paidPlayer.balance = balance;
  return paidPlayer
}

const player1 = createPlayer('sag1v', 700);
const paidPlayer = createPaidPlayer('sag1v', 700, 5);

console.log(player1)
console.log(paidPlayer)

This will output:

player1 {
  userName: "sag1v",
  score: 700,
  __proto__: playerFunctions {
     setScore: ƒ
  }
}

paidPlayer {
  userName: "sarah",
  score: 900,
  balance: 5,
  __proto__: paidPlayerFunctions {
    setUserName: ƒ,
    __proto__: playerFunctions {
      setScore: ƒ
    }
  }
}

As you can see, our createPlayer function implementation didn't change, but with the createPaidPlayer function we needed to pull some tricks.

In createPaidPlayer we are using the createPlayer to create the initial new object so we won't need to duplicate the logic of creating a new player, but unfortunately its linking our __proto__ to the wrong object, so we need to fix that with the Object.setPrototypeOf method. We pass it the target object (the newly created object that we need to fix it's __proto__ pointer) and we pass it the correct object we want it to point to, e.g paidPlayerFunctions.

We are not done yet though, because now we broke the linkage to the playerFunctions object which holds the setScore method. This is why we needed to link between paidPlayerFunctions and playerFunctions, again with Object.setPrototypeOf. This way we make sure our paidPlayer is linked to paidPlayerFunctions and then from there to playerFunctions.

This is a lot of code for a 2 level chaining, imagine the hassle for 3 or 4 levels of chaining.

Constructor Functions - Sub Classing

Now lets implement the same thing with constructor functions.

function Player(userName, score) {
  this.userName = userName;
  this.score = score;
}

Player.prototype.setScore = function(newScore) {
  this.score = newScore;
}


function PaidPlayer(userName, score, balance) {
  this.balance = balance;
  /* we are calling "Player" without the "new" operator
  but we use the "call" method,
  which allows us to explicitly pass a ref for "this".
  Now the "Player" function will mutate "this"
  and will populate it with the relevant properties */
  Player.call(this, userName, score);
}

PaidPlayer.prototype.setUserName = function(newName) {
  this.userName = newName;
}

// link PaidPlayer.prototype object to Player.prototype object
Object.setPrototypeOf(PaidPlayer.prototype, Player.prototype);


const player1 = new Player('sag1v', 700);
const paidPlayer = new PaidPlayer('sarah', 900, 5);

console.log(player1)
console.log(paidPlayer)

And we should get similar output to the previous implementation:

Player {
  userName: "sag1v",
  score: 700,
  __proto__: Player.prototype {
    setScore: ƒ
  }
}

PaidPlayer {
  userName: "sarah",
  score: 900,
  balance: 5,
  __proto__: PaidPlayer.prototype:{
    setUserName: ƒ,
    __proto__: Player.prototype {
      setScore: ƒ
    }
  }
}

This is effectively the same results that we got with the factory function patten but with some stuff that were automated for us by the new operator. It might saved us some lines of code but it did introduce some other challenges.

Our first challenge was how do we use the Player function to get the logic of creating the initial Player. We did this by calling it without the new operator (against all our instincts!) and using the .call method which allowed us to explicitly pass a reference for this, this way the Player function is not operating as a constructor method so it won't create a new object and assign it to this

function PaidPlayer(userName, score, balance) {
  this.balance = balance;
  /* we are calling "Player" without the "new" operator
  but we use the "call" method,
  which allows us to explicitly pass a ref for "this".
  Now the "Player" function will mutate "this"
  and will populate it with the relevant properties */
  Player.call(this, userName, score);
}

We are only using Player here to mutate our passed in this which is basically the newly created object inside the context of PaidPlayer.

Another challenge we have, is to link the instance returned by PaidPlayer to the functionality that instances of Player have, we did that with Object.setPrototypeOf and we linked PaidPlayer.prototype to Player.prototype.

// link PaidPlayer.prototype object to Player.prototype object
Object.setPrototypeOf(PaidPlayer.prototype, Player.prototype);

As you can see, the more things our engine is doing for us the less code we need to write, but as the amount of abstraction grow its harder for us to keep track about what is happening under the hood.

Class - Sub Classing

With classes we get much, much more abstraction, this means less code:

class Player {
  constructor(userName, score) {
    this.userName = userName;
    this.score = score;
  }

  setScore(newScore) {
    this.score = newScore;
  }
}

class PaidPlayer extends Player {
  constructor(userName, score, balance) {
    super(userName, score);
    this.balance = balance;
  }

  setUserName(newName) {
    this.userName = newName;
  }
}



const player1 = new Player('sag1v', 700);
const paidPlayer = new PaidPlayer('sarah', 900, 5);

console.log(player1)
console.log(paidPlayer)

And we get the same output as we got with the constructor functions:

Player {
  userName: "sag1v",
  score: 700,
  __proto__: Player.prototype {
    setScore: ƒ
  }
}

PaidPlayer {
  userName: "sarah",
  score: 900,
  balance: 5,
  __proto__: PaidPlayer.prototype:{
    setUserName: ƒ,
    __proto__: Player.prototype {
      setScore: ƒ
    }
  }
}

So as you see, classes are nothing but a syntactic sugar over the constructor functions. Well sort of 🤔

Remember this line from the docs:

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript’s existing prototype-based inheritance...

Yeah, primarily.

When we used the extends key word, we needed to use the super function, why?

Remember this (strange) line from the "Constructor Functions" section:

Player.call(this, userName, score)

so super(userName, score) is kind of a way to mimic it.

Well if we want to be a bit more accurate here, under the hood it uses a new feature that introduced with ES2015: Reflect.construct.

Quoting from the docs:

The static Reflect.construct() method acts like the new operator, but as a function. It is equivalent to calling new target(...args). It gives also the added option to specify a different prototype.

So we don't need to "hack" the constructor functions anymore. Basically under the hood the super is implemented with Reflect.construct. Its also important to mention that when we extend a class, inside the constructor body we can't use this before we run super(), because this is uninitialized yet.

class PaidPlayer extends Player {
  constructor(userName, score, balance) {
    // "this" is uninitialized yet...
    // super refers to Player in this case
    super(userName, score);
    // under the hood super is implemented with Reflect.construct
    // this = Reflect.construct(Player, [userName, score], PaidPlayer);
    this.balance = balance;
  }

  setUserName(newName) {
    this.userName = newName;
  }
}

Wrapping up

We learned about the the different ways we can connect objects, attaching data and logic and bundle it all together. We saw how "inheritance" works in JavaScript, chaining objects to other objects via the __proto__ property, sometimes with multiple levels of chaining.

We see it again and again, the more abstraction we get the more "stuff" are going on under the hood, which makes it harder for us to keep track on whats going on with our code.

Each pattern has it's pros and cons:

With Object.create we need to write more code but we have a more fine-grained control over our objects. Though it becomes tedious to do deep level chaining.
With the constructor functions we get some automated tasks done by JavaScript but the syntax may look a bit strange. We also need to make sure that our functions get invoked with the new key word or we will face nasty bugs. Deep level chaining isn't that great as well.
With classes we get a cleaner syntax and a built-in check that it was invoked with the new operator. Classes shines the most when we do "inheritance", we just use the extends key word and invoking super() instead of jumping hoops with the other patterns. The syntax is also closer to other languages and it looks like an easy thing to learn. Though this is also a downside because as we saw, its so different than classes in other languages, we still use the old "Prototypal Inheritance" with a lot of layers of abstractions over it.

Hope you found this article helpful, if you have something to add or any suggestions or feedbacks I would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

React reusable logic - A tale of 3 knights and a Primitive

Sagiv ben giat — Sat, 02 Nov 2019 17:52:17 +0000

The evolution of sharing logic in react

Originally posted at my personal blog debuggr.io

In this article we will learn about the options and patterns for sharing behavior and logic across components, we will travel in time and explore the evolution of logic sharing in react.

The challenge

Our challenge is to share logic across components, in this case we have a component that tracks the movement of the mouse and we want to share the logic of the mouse movement tracking.

This is how our application looks like:

We are going back in time to the first version of react (this will work if you use react version 15.6.2 and below) and we are using the good old React.createClass API.

This is how our component looks like now:

const App = React.createClass({
  getInitialState() {
    return { x: "", y: "" };
  },

  onMouseMove(e) {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  },

  render() {
    const { x, y } = this.state;
    return (
      <div className="app" onMouseMove={this.onMouseMove}>
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
});

What we want to do is to extract the logic related to the tracking of the mouse and be able to use it on any component we want in the future.

So basically we want to extract the state and the onMouseMove handler.

Mixins - The children of the forest

Since the beginning of time (or at least since october 2013), mixins were a way to share logic across components. It was fairly easy to use:

const mouseMoveMixin = {
  getInitialState() {
    return { x: "", y: "" };
  },

  onMouseMove(e) {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  }
};

const App = React.createClass({
  mixins: [mouseMoveMixin],

  render() {
    const { x, y } = this.state;
    return (
      <div className="app" onMouseMove={this.onMouseMove}>
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
});

As you can see, a mixin is just an object that can be placed inside the mixins array property.

Mixins were great and solved the initial challenge of sharing logic across components, though they did have some issues.

Why mixins are dead?

ES2015 class - For starters, React.createClass is dead. When the ES2015 class feature was released to the wild, I guess the react team realized that native classes are better than maintaining a react implementation of classes. So without React.createClass we no longer have support for mixins.

indirection - The second reason mixins were abandoned, is the indirection of state and variables. If we look at the code again, imagine that the mouseMoveMixin mixin was in a different file or maybe we might have another mixin in our mixins array, we might get confused as where the x and y in our state comes from:

const App = React.createClass({
  mixins: [mouseMoveMixin, geoMixin],

  render() {
    const { x, y } = this.state; // where is that coming from?
    return (
      <div className="app" onMouseMove={this.onMouseMove}>
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
});

key conflicts - Another pitfall with mixins is the key conflict. Imagine that we have 2 mixins and both output the same key for our state:

const mouseMoveMixin = {
  getInitialState() {
    return { x: "", y: "" };
  },

  onMouseMove(e) {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  }
};

const geoMixin = {
  getInitialState() {
    return { x: 0.22, y: 1.3333333 };
  }
}

const App = React.createClass({
  mixins: [mouseMoveMixin, geoMixin],

  render() {
    const { x, y } = this.state;
    return (
      <div className="app" onMouseMove={this.onMouseMove}>
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
});

Luckily react will throw an error and warn us about it:

HOC - The knight in shining armor

With the appearance of ES2015 classes and the deprecation of mixins, a new pattern emerged, Higher-Order Components.

From react's documentations:

A higher-order component (HOC) is an advanced technique in React for reusing component logic. HOCs are not part of the React API, per se. They are a pattern that emerges from React’s compositional nature.

Concretely, a higher-order component is a function that takes a component and returns a new component.

So for our use case, a HOC might look something like this:

const withMouse = Component => {
  return class extends React.Component {
    state = { x: "", y: "" };

    onMouseMove = e => {
      this.setState({
        x: e.clientX,
        y: e.clientY
      });
    };

    render() {
      return (
        <div onMouseMove={this.onMouseMove}>
          <Component {...this.props} {...this.state} />
        </div>
      );
    }
  };
};

And this is how we would use it:

class App extends React.Component {
  render() {
    // we now get the x and y via props
    const { x, y } = this.props;
    return (
      <div className="app">
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
};

App = withMouse(App)

Note that now we are getting the x and y variables from props and not storing them in a state. Actually our HOC manage that state for us, this is the very logic we wanted to share.

So it seems that we achieved our initial goal here, we are using ES2015 classes AND sharing our logic. Though lets see if we solved the issues we had with mixins:

ES2015 class - Yeah, as mentioned above we now support ES2015 classes.

Indirection - Seems like we still have an indirection issue here, we still ask ourself "where is this prop comes from?"

Key conflicts - This issue still exists, if we wrap our component with multiple HOC's, one might override the other.

const withMouse = Component => {
  return class extends React.Component {
    state = { x: "", y: "" };

    onMouseMove = e => {
      this.setState({
        x: e.clientX,
        y: e.clientY
      });
    };

    render() {
      return (
        <div onMouseMove={this.onMouseMove}>
          <Component {...this.props} {...this.state} />
        </div>
      );
    }
  };
};

const withXProp = Component => {
  return class extends React.Component {
    state = { x: `I'm X!` };
    render() {
      return <Component {...this.props} {...this.state} />;
    }
  };
};

class App extends React.Component {
  render() {
    const { x, y } = this.props;
    return (
      <div className="app">
        <div>{`${x} - ${y}`}</div>
      </div>
    );
  }
}

App = withMouse(withXProp(App));

In fact, we went a step back. With mixins we at least had a warning that we have a conflict with keys, with HOC's we don't get that warning and as you can see, our application has a bug.

Static composition - With HOCs we compose at "build time" or "declaration time", this means we can't do dynamic composition. In order to do dynamic composition we must put that logic inside the render method, but using a HOC inside render will introduce an unexpected behavior such as state loss.

HOC's boiler plate

You might not notice but our HOC is missing some important things.

Component Identity - When we wrap a component with a HOC we introduce another level of nodes in our tree, but our new node doesn't have a name. Lets see how the node tree looks like in react dev-tools:

In order to fix this and give a meaningful name for the wrapping component we need to change the displayName property of the component our HOC creates:

const withMouse = Component => {
  class Inner extends React.Component {
    state = { x: "", y: "" };

    onMouseMove = e => {
      this.setState({
        x: e.clientX,
        y: e.clientY
      });
    };

    render() {
      return (
        <div onMouseMove={this.onMouseMove}>
          <Component {...this.props} {...this.state} />
        </div>
      );
    }
  }

  Inner.displayName = `withMouse(${Component.displayName || Component.name})`;

  return Inner;
};

const withXProp = Component => {
  class Inner extends React.Component {
    state = { xy: `I'm X!` };
    render() {
      return <Component {...this.props} {...this.state} />;
    }
  };

  Inner.displayName = `withXProp(${Component.displayName || Component.name})`;

  return Inner;
};

We no longer return immediately the component, we first declare it - Inner in this case, then we manipulate it's displayName property and return the component.

This is how it looks like now in react dev-tools:

Static properties - When we wrap our component with a HOC we kind of "hijacking" the static properties, for example:

App.someStaticProperty = "I'm a static property";
App = withMouse(App);
console.log(App.someStaticProperty); // undefined

In order to fix this we need to somehow hoist our static properties up to the wrapping component, this is not an easy task as we need to know the names of the properties. Luckily there is a library that's already doing it for us - hoist-non-react-statics

import hoistNonReactStatics from 'hoist-non-react-statics';

const withMouse = Component => {
  class Inner extends React.Component {
    state = { x: "", y: "" };

    onMouseMove = e => {
      this.setState({
        x: e.clientX,
        y: e.clientY
      });
    };

    render() {
      return (
        <div onMouseMove={this.onMouseMove}>
          <Component {...this.props} {...this.state} />
        </div>
      );
    }
  }

  Inner.displayName = `withMouse(${Component.displayName || Component.name})`;

  return hoistNonReactStatics(Inner, Component);
};

class App extends React.Component {...}

App.someStaticProperty = "I'm a static property";
App = withMouse(App);
console.log(App.someStaticProperty); // I'm a static property

Loosing ref - What happens if someone wants to reference our wrapped component? the App component in our case.

App = withMouse(App);
let ourRef;
const rootElement = document.getElementById("root");
ReactDOM.render(<App ref={node => ourRef = node} />, rootElement);
console.log(ourRef) // Inner??

Because ref is a special prop that handled by react and doesn't get passed like other props (same as key) we need to handle it somehow. We have couple of options here:

Using an explicit prop for the ref:

const withMouse = Component => {
    class Inner extends React.Component {
        state = { x: "", y: "" };

        onMouseMove = e => {
            this.setState({
                x: e.clientX,
                y: e.clientY
            });
        };

        render() {
            const { componentRef, ...restOfProps } = this.props;
            return (
                <div onMouseMove={this.onMouseMove}>
                    <Component {...restOfProps} ref={componentRef} {...this.state} />
                </div>
            );
        }
    }

    Inner.displayName = `withMouse(${Component.displayName || Component.name})`;
    return hoistNonReactStatics(Inner, Component);
};

class App extends React.Component {...}

App = withMouse(App);

let ourRef;
const rootElement = document.getElementById("root");
ReactDOM.render(<App componentRef={node => (ourRef = node)} />, rootElement);
console.log(ourRef); // App

Note how we need to introduce another prop to our API: componentRef. 🤮

Using the forwardRef API which is available since React v16.3.0

const withMouse = Component => {
    class Inner extends React.Component {
        state = { x: "", y: "" };

        onMouseMove = e => {
            this.setState({
                x: e.clientX,
                y: e.clientY
            });
        };

        render() {
            const { componentRef, ...restOfProps } = this.props;
            return (
                <div onMouseMove={this.onMouseMove}>
                    <Component {...restOfProps} ref={componentRef} {...this.state} />
                </div>
            );
        }
    }

    Inner.displayName = `withMouse(${Component.displayName || Component.name})`;

    const withRef = forwardRef((props, ref) => {
        return <Inner {...props} componentRef={ref} />
    });

    return hoistNonReactStatics(withRef, Component);
};

class App extends React.Component {...}

App = withMouse(App);

let ourRef;
const rootElement = document.getElementById("root");
ReactDOM.render(<App ref={node => (ourRef = node)} />, rootElement);
console.log(ourRef); // App

With forwardRef we can abstract this behavior and we don't need to introduce another prop to our API, thus the consumers of the component would be able to pass the regular ref prop.

This is the minimum effort we need to put for our HOC and we will need to do that for each and every one of them! 😫

Render props - A Law-Worthy Knight

A quote from react documentations

The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.

A component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.

You don't have to call your prop render, in fact this is also common to use the children prop as a function.
So for our use case the "render prop" or "children as a function" pattern might look like this:

class Mouse extends React.Component {
  state = { x: "", y: "" };

  onMouseMove = e => {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  };

  render() {
    const { children } = this.props;
    return (
      <div onMouseMove={this.onMouseMove}>
        {children(this.state)}
      </div>
    );
  }
}

class App extends React.Component {
  render() {
    return (
      <div className="app">
        <Mouse>
          {mouseState => (
             <div>{`${mouseState.x} - ${mouseState.y}`}</div>
          )}
        </Mouse>
      </div>
    );
  }
}

Lets review the issues we had with mixins and HOCs and see if we still have them:

ES2015 classes - Yeah, we can use classes.

Indirection - We no longer have an indirection, we know exactly where the values are coming from.

Key conflicts - We can name our variables whatever we want, so we have no conflicts:

class Mouse extends React.Component {
  state = { x: "", y: "" };

  onMouseMove = e => {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  };

  render() {
    const { children } = this.props;
    return <div onMouseMove={this.onMouseMove}>{children(this.state)}</div>;
  }
}

class Xprop extends React.Component {
  state = { x: "I'm X!" };
  render() {
    return this.props.children(this.state);
  }
}

class App extends React.Component {
  render() {
    return (
      <div className="app">
        <Mouse>
          {mouseState => (
            <Xprop>
              {xPropstate => (
                <div>
                  <div>{`${mouseState.x} - ${mouseState.y}`}</div>
                  <div>{xPropstate.x}</div>
                </div>
              )}
            </Xprop>
          )}
        </Mouse>
      </div>
    );
  }
}

Boiler plate - With this pattern we are giving back the responsibility of what to render to the consumers. With HOCs, we were responsible for what to render thus we had a lot of things to take care of, like component's name, static properties and refs. Now we don't need to care about any of those things as the consumer of our component is doing the render part.

Dynamic composition - Because the consumers are doing the render part, it allows them to dynamically compose what to render. Like render ComponentA or ComponentB based on the value of x, something they didn't able to achieve with our HOC.

Pitfalls - Render props did solve most if not all of our issues but they do come with some caveats. Quoting react's documentations:

Using a render prop can negate the advantage that comes from using React.PureComponent if you create the function inside a render method. This is because the shallow prop comparison will always return false for new props, and each render in this case will generate a new value for the render prop.

In this case we can get around this issue by creating an instance method (outside the render method):

class Mouse extends React.PureComponent {
  state = { x: "", y: "" };

  onMouseMove = e => {
    this.setState({
      x: e.clientX,
      y: e.clientY
    });
  };

  render() {
    const { children } = this.props;
    return <div onMouseMove={this.onMouseMove}>{children(this.state)}</div>;
  }
}

class App extends React.Component {
  renderMouse = mouseState => (
    <div>{`${mouseState.x} - ${mouseState.y}`}</div>
  )
  render() {
    return (
      <div className="app">
        <Mouse>
          {this.renderMouse}
        </Mouse>
      </div>
    );
  }
}

Render props callback hell - If we compose multiple render props we might get an ugly nested callbacks tree in our render.

Hooks - The new Primitives

A quote from react's documentations:

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class

For me, hooks are like mixins on steroids. They are not a pattern like HOCs or render props but a new primitive exposed to us by react. If so far components were the smallest building blocks, now we get an even smaller part, hooks.

Lets see how our code might look like with hooks:

import React, { useState } from "react";

function useMouse() {
  const [position, setPosition] = useState({ x: 0, y: 0 });
  const onMouseMove = e => {
    setPosition({
      x: e.clientX,
      y: e.clientY
    });
  };
  return [position, onMouseMove];
}

function App() {
  const [mousePosition, onMouseMove] = useMouse();
  return (
    <div className="app">
      <div onMouseMove={onMouseMove}>
        {`${mousePosition.x} - ${mousePosition.y}`}
      </div>
    </div>
  );
}

As you can see, with less code we managed to achieve better results. Lets review our issues from other solutions again:

sharing logic - Check

ES2015 classes - No need for classes anymore, we are using plain functions.

Indirection - We know exactly where our data is coming from, so no indirection.

Key conflicts - We have no conflicts because we can name our variables whatever we want.

Boiler plate - We have no boiler plate to worry about (unlike HOCs)

Dynamic composition - We can dynamically compose our tree based on the values we received from our custom hook.

Smaller node tree - We didn't mention it earlier but we managed to reduce the size of our tree, meaning we have less levels of nodes than we had with HOCs and render props.

Sharing none-UI logic - Because hooks are not components, they can return anything and not only valid JSX. This allow us to share logic that is not UI specific, like useFetch or useLocalStorage etc.

Seems like hooks managed to solve our initial challenge of sharing logic across components without the issues that raised by the other solutions, in fact they also provide some extra goodies like smaller code foot-print and decoupling logic from UI.

Wrapping up

We made a long journey, from the built-in mixins to patterns like HOCs and render-props and finally to the great addition of react, hooks. In my opinion, we kind of made a full circle. I think that mixins were the ultimate solution but as mentioned above they had some issues. With time and some milage, we got hooks which for me are sort of a re-write of mixins with all the experience and knowledge gained by the react team. Sometimes we need to make a full circle to really understand the challenges we are facing and find the best solutions for them.

Hope you found this article helpful, if you have something to add or any suggestions or feedbacks I would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

React race condition bug

Sagiv ben giat — Fri, 25 Oct 2019 15:35:26 +0000

Originally posted on my personal blog debugger.io

If your application is depended on a state that gets updated asynchronously, there is a good chance you have a bug. The bad news is that its hard or even almost impossible to reproduce in production. The good news is that you now know about it and we will learn how to reproduce it and fix it.

In this article I will use a demo application that I used in a previous article React state update on an unmounted component. Although reading it is not a prerequisite, I do think its a good idea to read it.

👀 I've uploaded a starter repo to github so you won't have to copy paste the code.
You can clone and run it locally or use the import feature of codesandbox.io

This is how our application looks like:

Basically we are selecting a pet and showing some info that we "fetch" from the server.

This is how the Pets component looks like:

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

Our Pets component uses the useReducer hook to store some state.
Lets see the petsReducer and the initial state:

const initialState = { loading: false, selectedPet: "", petData: null }

function petsReducer(state, action) {
  switch (action.type) {
    case "PET_SELECTED": {
      return {
        ...state,
        selectedPet: action.payload
      };
    }
    case "FETCH_PET": {
      return {
        ...state,
        loading: true,
        petData: null
      };
    }
    case "FETCH_PET_SUCCESS": {
      return {
        ...state,
        loading: false,
        petData: action.payload
      };
    }

    case "RESET": {
      return initialState;
    }

    default:
      throw new Error( `Not supported action ${action.type}` );
  }
}

As you can see theres nothing special here, a simple reducer that manage our state.

The Pets component also use the useEffect hook for some side effects like fetching the data of our selected pet, we invoke the getPet function which returns a Promise and we dispatch the FETCH_PET_SUCCESS action with the returned data as the payload to update our state.

Note that getPet is not really hitting a server end-point, its just a function that simulate a server call. This is how it looks like:

const petsDB = {
  dogs: { name: "Dogs", voice: "Woof!", avatar: "🐶" },
  cats: { name: "Cats", voice: "Miauuu", avatar: "🐱" }
};

export function getPet(type) {
  return new Promise(resolve => {
    // simulate a fetch call
    setTimeout(() => {
      resolve(petsDB[type]);
    }, 1000);
  });
}

As you see, its nothing but a setTimeout inside a Promise.

The bug

So far everything looks great, we chose a pet type from the Drop-down and we get the info 1000ms later. Though when we are dealing with asynchronous operations we can't determine at what point of time exactly we are running our code, moreover we need to handle 2 or more operations simultaneously. What happens when the first operation is slower than the second operation? How are we dealing with the results?

Imagine this scenario:

The user select the Cats option.
We are fetching the Cats data from the server.
The user now select the Dogs option.
We are fetching the Dogs data from the server.
for some reason, the Dogs data received before the Cats data (yeah it happens!).
We display the Dogs data on the screen.
Couple of milliseconds later, the Cats data is received.
We display the Cats data on the screen, but the Drop-down still shows the Dogs as selected.

This is how it looks like on the screen:

How did we managed to do it? just a hard-coded longer delay for the cats type:

export function getPet(type) {
  const delay = type === "cats" ? 3500 : 500;
  return new Promise(resolve => {
    // immulate fetch call
    setTimeout(() => {
      resolve(petsDB[type]);
    }, delay);
  });
}

The problem

Why is that happening? lets revisit our data fetching logic in useEffect:

  useEffect(() => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

As you can see, our state update (using dispatch) is running inside the .then() function. It will run only when the Promise returned by getPet is resolved. When the user select a different option before the Promise is resolved, we trigger getPet again with its own .then() function. When the second (but faster) call is resolved, we run the function passed to .then() and updating the state with the passed in data object (Dogs data). When the first call is resolved, we run the function passed to it's .then() and updating the state with the passed in data object, a WRONG and none relevant data! Yes, the one with the cats 🙀🙀🙀

The solution

One possible solution is to cancel the first request, we can use the AbortController.abort() (⚠️ experimental technology) or we can implement a Cancelable promise.

If you can't or don't want to use these solutions, there is another solution. Basically our problem is that we store a key for the selected pet but we update the data object without checking that the data correspond to that key. If we will check that the key and the data correspond and only then we will trigger the update, we will not have this problem.

Lets see how can we do that.

Trial #1 (❌)

useEffect(() => {
  let _previousKey = pets.selectedPet;
  if (pets.selectedPet) {
    dispatch({ type: "FETCH_PET" });
    getPet(pets.selectedPet).then(data => {
      if (_previousKey === pets.selectedPet) {
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      }
    });
  } else {
    dispatch({ type: "RESET" });
  }
}, [pets.selectedPet]);

Here we are storing the selectedPet key in a different temp variable _previousKey and then inside the .then() function we check if the "current" selectedPet matches _previousKey.

This won't work! We just override the _previousKey variable each time the useEffect is running, so we end up matching the same value over and over. This is also true if we were to declare the _previousKey variable outside the useEffect at the function component level scope, because it will run on each render.

Trial #2 (❌)

let _previousKey;

function Pets() {
  //... 

  useEffect(() => {
    _previousKey = pets.selectedPet;
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if (_previousKey === pets.selectedPet) {
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

  return (...);
}

Here we are declaring the _previousKey outside the component's scope, this way we always get the latest value and not overriding it on each render or effect call.

Although it seems to be working fine and our problem is solved, we introduce a new bug. If we will have 2 different instances of Pets rendered, they will "share" this variable and will override it to each other.

Trial #3 (✔️)

function Pets() {
  //...
  const _previousKeyRef = useRef(null);

  useEffect(() => {
    _previousKeyRef.current = pets.selectedPet;
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if (_previousKeyRef.current === pets.selectedPet) {
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

  return (...);
}

In trial #2 we made some progress but we ended up with kind of a "global" variable. What was missing is a variable attached to the instance of our component. In class components we would use the this key word to reference the instance -- this._previousKey. In function components the this key word doesn't reference the component's instance because there is no instance (you can read more about the this key word in JavaScript - The "this" key word in depth). React solved the lack of instance issue with the useRef hook. Think of it as a mutable state object for your component that doesn't trigger a re-render when you update it (unlike useState or useReducer).

This way we can safely store the _previousKey and compare it to the current selectedPet and only if they match, update our state with the relevant data object. If you run the code now you will see that we fixed our bug 🙌

Trial #3.5 (✔️)

useEffect(() => {
  let abort = false;

  if (pets.selectedPet) {
    dispatch({ type: "FETCH_PET" });
    getPet(pets.selectedPet).then(data => {
      if(!abort){
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      }
    });
  } else {
    dispatch({ type: "RESET" });
  }

  return () => abort = true;

}, [pets.selectedPet])

This is another possible solution. Instead of keeping track on the matching values, we can just use a simple flag that indicates if we should keep with our update state operation. Every time the effect runs we are initialising the abort variable with false, inside the cleanup function of the effect we set it to true. the effect will only run at first render and every time one of the values passed to the dependencies array is changed. The cleanup function will run just before each cycle of the effect and when the component is unmounted.

This works great and probably the preferred solution for some people, but keep in mind that now your effect can't have other none related logic with none related dependencies in the array (and it shouldn't have!), because then the effect will re-run if those dependencies change and will trigger the cleanup function which will flip the abort flag.

Nothing is stopping you from having multiple useEffect functions, one for each logic operation.

Custom useEffect

If we want to get real crazy with our hooks, we can create our own custom useEffect (or useLayoutEffect) which will provide us the "current status" of the effect:

function useAbortableEffect(effect, dependencies) {
  const status = {}; // mutable status object
  useEffect(() => {
    status.aborted = false;
    // pass the mutable object to the effect callback
    // store the returned value for cleanup
    const cleanUpFn = effect(status);
    return () => {
      // mutate the object to signal the consumer
      // this effect is cleaning up
      status.aborted = true;
      if (typeof cleanUpFn === "function") {
        // run the cleanup function
        cleanUpFn();
      }
    };
  }, [...dependencies]);
}

And we will use it in our Pet component like this:

  useAbortableEffect((status) => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if(!status.aborted){
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

Note how our custom effect callback now accepts a status argument which is an object that contains an aborted boolean property. If it is set to true, that means our effect got cleaned and re-run (which means our dependencies are changed or the component was un-mounted).

I kind of like this pattern and i wish react useEffect would get us this behavior out of the box. I even created an RFC on the react repo for this if you want to comment or improve it.

Good news

Note that this is not a react specific problem, this is a challenge that most if not all of the UI libraries or framework are facing, due to the nature of asynchronous operations and state management. The good news is that the react team is working on a great feature called Concurrent Mode and one of its features is Suspense which should cover this issue out of the box.

Wrapping up

We saw that a simple component with a state and asynchronous operation can produce a nasty bug, we might not even know it's there until we face it in production. My conclusion is that whenever we update a state (can be local or in a state manager) inside an asynchronous callback, we must check if the arguments that we passed to the asynchronous function is corresponding to the data we received in the callback.

Hope you found this article helpful, if you have a different approach or any suggestions I would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io

React state update on an unmounted component

Sagiv ben giat — Thu, 24 Oct 2019 15:45:54 +0000

Originally posted on my personal blog debugger.io

If you are a react developer, there is a good chance that you faced this warning at least once:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

In order to understand how to fix this warning, we need to understand why it is happening. We will need to reproduce it in a consistent way.

⚠️ Note that in this article i use react hooks, if you are using react class components you may see in the warning a reference to componentWillUnmount instead of the useEffect cleanup function.

Reproduce the warning

👀 I've uploaded a starter repo to github so you won't have to copy paste the code.
You can clone and run it locally or use the import feature of codesandbox.io

If we look at the warning again, we can see that there are 2 main parts playing a role here:

A React state update
An unmounted component

In order to create these, we will build this simple drop-down with asynchronous data fetching

State updates

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

Here we have the Pets component, it uses the useReducer hook to store some state.
Lets see the petsReducer and the initial state:

const initialState = { loading: false, selectedPet: "", petData: null }

function petsReducer(state, action) {
  switch (action.type) {
    case "PET_SELECTED": {
      return {
        ...state,
        selectedPet: action.payload
      };
    }
    case "FETCH_PET": {
      return {
        ...state,
        loading: true,
        petData: null
      };
    }
    case "FETCH_PET_SUCCESS": {
      return {
        ...state,
        loading: false,
        petData: action.payload
      };
    }

    case "RESET": {
      return initialState;
    }

    default:
      throw new Error( `Not supported action ${action.type}` );
  }
}

As you can see theres nothing special here, a simple reducer that manage our state.

Note that getPet is not really hitting a server end-point, its just a function that simulate a server call. This is how it looks like:

const petsDB = {
  dogs: { name: "Dogs", voice: "Woof!", avatar: "🐶" },
  cats: { name: "Cats", voice: "Miauuu", avatar: "🐱" }
};

export function getPet(type) {
  return new Promise(resolve => {
    // simulate a fetch call
    setTimeout(() => {
      resolve(petsDB[type]);
    }, 1000);
  });
}

As you see, its nothing but a setTimeout inside a Promise .

Our App is basically just rendering this Pets component:

function App() {
  return (
    <div>
      <Pets />
    </div>
  );
}

Ok first part of our problem is accomplished, thats the React state update , now we need to create the 2nd part - An unmounted component .

Un-mounting a component

This is relatively easy to accomplish using a state and a conditional rendering, we will store a boolean flag at the App level and we will render the <Pets /> component accordingly while using a toggle button.

function App() {
  const [showPets, setShowPets] = useState(true);

  const toggle = () => {
    setShowPets(state => !state);
  };

  return (
    <div>
      <button onClick={toggle}>{showPets ? "hide" : "show"}</button>
      {showPets && <Pets />}
    </div>
  );
}

This is how our application should look like

Reproduction

Ok, now that we have both conditions for the warning to appear lets try it. If we look again at the warning:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

Lets focus on this line here:

React state update on an unmounted component

If we select a pet, we know that it will take our getPet at least 1 second to return our data. After our data is returned we are updating the state, if we will un-mount the Pet component before that 1 second (before our data is received) we will trigger an update on an unmounted component.

So this is how you do it:
*If you can't make it with a 1 second delay, try to increase the timeOut in the getPet function.

OK this is part one of our task, now we need to fix it.

The fix

You may be surprised but the fix for this issue is actually the easy part. React is providing a clear and a very helpful message, with a guidance to the solution:

To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

Well, we may not exactly subscribing to anything here, but we do have an asynchronous tasks, remember the getPet asynchronous function:

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

So basically we just need to NOT update the state in the callback if the component is not mounted already.

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    let mounted = true;
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if(mounted){
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }

    return () => mounted = false;

  }, [pets.selectedPet]);

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

Every time our effect will run, we are setting a local variable mounted to true, we set it to false on the cleanup function of the effect (like suggested by react). And most importantly, we are updating the state if and only if that value is true, that is if the component is un-mounted meaning our variable is set to false, it wont enter the if block.

So this is it, we are no longer receiving the warning:

Bonus Tip

We set a local variable inside the useEffect scope, if we want to re-use this variable inside another useEffect we can use useRef, which is sort of a none rendering state for components.

For example:

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);
  const isMountedRef = useRef(null);

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    isMountedRef.current = true;
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if(isMountedRef.current){
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }

    return () => isMountedRef.current = false;

  }, [pets.selectedPet]);

  useEffect(() => {
      // we can access isMountedRef.current here as well
  })

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

The great thing about hooks is that we can extract this tiny logic to a custom hook and reuse it across components. One possible implementation can be something like this:

function useIsMountedRef(){
  const isMountedRef = useRef(null);

  useEffect(() => {
    isMountedRef.current = true;
    return () => isMountedRef.current = false;
  });

  return isMountedRef;
}

function Pets() {
  const [pets, dispatch] = useReducer(petsReducer, initialState);
  const isMountedRef = useIsMountedRef();

  const onChange = ({ target }) => {
    dispatch({ type: "PET_SELECTED", payload: target.value });
  };

  useEffect(() => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if(isMountedRef.current){
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet, isMountedRef]);

  return (
    <div>
      <select value={pets.selectedPet} onChange={onChange}>
        <option value="">Select a pet</option>
        <option value="cats">Cats</option>
        <option value="dogs">Dogs</option>
      </select>
      {pets.loading && <div>Loading...</div>}
      {pets.petData && <Pet {...pets.petData} />}
    </div>
  );
}

Custom useEffect

If we want to get real crazy with our hooks, we can create our own custom useEffect (or useLayoutEffect) which will provide us the "current status" of the effect:

function useAbortableEffect(effect, dependencies) {
  const status = {}; // mutable status object
  useEffect(() => {
    status.aborted = false;
    // pass the mutable object to the effect callback
    // store the returned value for cleanup
    const cleanUpFn = effect(status);
    return () => {
      // mutate the object to signal the consumer
      // this effect is cleaning up
      status.aborted = true;
      if (typeof cleanUpFn === "function") {
        // run the cleanup function
        cleanUpFn();
      }
    };
  }, [...dependencies]);
}

And we will use it in our Pet component like this:

  useAbortableEffect((status) => {
    if (pets.selectedPet) {
      dispatch({ type: "FETCH_PET" });
      getPet(pets.selectedPet).then(data => {
        if(!status.aborted){
          dispatch({ type: "FETCH_PET_SUCCESS", payload: data });
        }
      });
    } else {
      dispatch({ type: "RESET" });
    }
  }, [pets.selectedPet]);

I kind of like this pattern and i wish react useEffect would get us this behavior out of the box. I even created an RFC on the react repo for this if you want to comment or improve it.

Wrapping up

We saw how a simple component with an asynchronous state update may yield this common warning, think about all those components you have with a similar case. Make sure you check if the component is actually mounted before you perform a state update.

Hope you found this article helpful, if you have a different approach or any suggestions i would love to hear about them, you can tweet or DM me @sag1v. 🤓

For more articles you can visit debuggr.io