debuggr.io

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

Fri, 27 Feb 2026 00:00:00 GMT

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.

(This is a post published on my blog at debuggr.io. You can read it online here.)

Stop Asking AI for Answers - Start Shipping Fixes

Thu, 05 Feb 2026 00:00:00 GMT

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.

(This is a post published on my blog at debuggr.io. You can read it online here.)

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

Tue, 09 Dec 2025 00:00:00 GMT

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.

(This is a post published on my blog at debuggr.io. You can read it online here.)

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

Thu, 22 May 2025 00:00:00 GMT

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.

(This is a post published on my blog at debuggr.io. You can read it online here.)

React - setState is not a function

Sat, 14 Mar 2020 00:00:00 GMT

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). 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

React - Cannot read property 'map' of undefined

Thu, 12 Mar 2020 00:00:00 GMT

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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

JavaScript - Closure in depth

Thu, 21 Nov 2019 00:00:00 GMT

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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

JavaScript - The prototype chain in depth

Fri, 08 Nov 2019 00:00:00 GMT

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 playerFunctions 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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

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

Fri, 01 Nov 2019 00:00:00 GMT

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:

_{^{You can use the create-react-class library instead of using an old version of react.}}

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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

React race condition bug

Fri, 25 Oct 2019 00:00:00 GMT

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 initializing 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, improve it or just up-vote with a like so it will have a better chance to get implemented.

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 React 18 introduced concurrent rendering capabilities (see React v18), and Suspense helps coordinate loading states in modern apps.

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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

React state update on an unmounted component

Wed, 23 Oct 2019 00:00:00 GMT

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]);

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. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

JavaScript - The "this" key word in depth

Wed, 21 Aug 2019 00:00:00 GMT

In this article we will learn how to identify and recognize what this refers to in a given context and we will explore what rules and conditions are taken under consideration by the engine to determine the reference of the this key word.

The challenge

One of the most challenging concepts in JavaScript is the this key word, maybe because it is so different than other languages or maybe because the rules to determine it’s value are not that clear.

Lets quote a paragraph from MDN:

In most cases, the value of this is determined by how a function is called (runtime binding). It can’t be set by assignment during execution, and it may be different each time the function is called…

Challenging indeed, on one hand it says that this is determined at run-time - i.e, a dynamic binding, but on the other hand it says In most cases..., meaning it can be statically bound. How doe’s something can be both static and dynamic and how can we be sure which one it is at a given context? This is exactly what we are going to find out now!

What is static?

Let’s look at an example of something static in JavaScript, like the “Local variable environment” - often refers to as scope.

Every time a function is invoked, a new execution context is created and pushed to the top of the call-stack (when our application starts, there is already a default execution context which is often referred to as the global-context). Each execution context contains a “Local variable environment” which usually referred to as the local-scope (or global-scope in the global execution context).

Given this code snippet:

function foo() {
  var message = 'Hello!';
  console.log(message);
}
foo();

Just by looking at foo’s declaration, we know what scope message belongs to - the local scope of the foo function execution-context. Because var statement declares a function-scoped variable.

Another example:

function foo() {
  var message = 'Hello';
  {
    let message = 'there!';
    console.log(message); // there!
  }
  console.log(message); // Hello
}

foo();

Notice how inside the block we get a different result than outside of it, that’s because let statement declares a block scope local variable.

We know what to expect just by looking at the deceleration of the function because scope in JavaScript is statically determined (lexical), or at “Design time” if you will. No matter where and how we will run the function, it’s local scope won’t change. In other words, we can say that the scope of a variable is depended on where the variable was declared.

What is dynamic?

If static means ”Where something WAS declared”, we might say dynamic means ”How something WILL run”.

Lets imagine for a moment that scope was dynamic in JavaScript:

note, this is not a real syntax ⚠️

function foo(){
  // not a real syntax!!! ⚠️
  let message = if(foo in myObj) "Hello" else "There"
  console.log(message)
}

let myObj = {
  foo
};

myObj.foo() // Hello
foo() // There

As you can see, in contrast to the static scope example we now can’t determine the final value of message just by looking at the declaration of foo, we will need to see where and how its being invoked. That’s because the value of the message variable is determined upon the execution of foo with a set of conditions. It may look strange but this is not that far away from the truth when we are dealing with the this context, every time we run a function the JavaScript engine is doing some checks and conditionally set the reference of this.

There are some rules, and order matters. You know what, lets just write them out as if we are writing the engine ourselves:

note, this is not a real syntax ⚠️

function foo(){
  // not real syntax!!! ⚠️
  if(foo is ArrowFunction) doNothing;
  else if(foo called with new) this = {};
  else if(
    foo called with apply ||
    foo called with call  ||
    foo called with bind  ||
  ) this = thisArg
  else if(foo called within an object) this = thatObject
  else if(strictMode){
    this = undefined
  } else{
    // default binding, last resort
    this = window;
    // or global in node
  }

  console.log(this);
  // who knows? we need to see where and how it runs
}

Seems a bit cumbersome and complex, maybe this flow chart will provide a better visualization:

The flow chart

As you can see we can split the flow into two parts:

Static binding - The arrow function
Dynamic binding - The rest of the conditions

Lets walk them through:

Is it an arrow function? - If the relevant execution context is created by an arrow function then do nothing, meaning this will be whatever it was set by the wrapping execution context.
Was the function called with new?
When invoking a function with the new key word the engine will do some things for us: _ Create a new object and set this to reference it. _ Reference that object’s __proto__ (called [[Prototype]] in the spec) to the function’s prototype object. * Return the newly created object (this).
```
So for our purpose to determine what `this` is, we know it will be a new object that was created automatically just by invoking the function with the `new` key word.
```
Was the function called with call / apply or bind? - Then set this to whatever passed as the first argument.
Was the function called as an object method - Then set this to the object left to the dot or square brackets.
Is strict mode on? - Then this is undefined
default case - this will reference the global / window.

The Quiz

The best way to measure our understanding is to test ourselves, so lets do a quiz. open the flowchart on a new tab and walk through it from top to bottom for each question (answers are listed below):

Try to answer what will be printed to the console.

Question #1

function logThis() {
  console.log(this);
}

const myObj = {
  logThis,
};

myObj.logThis();

Question #2

function logThis() {
  console.log(this);
}

const myObj = {
  foo: function () {
    logThis();
  },
};

myObj.foo();

Question #3

const logThis = () => {
  console.log(this);
};

const myObj = {
  foo: logThis,
};

myObj.foo();

Question #4

function logThis() {
  console.log(this);
}

const myObj = { name: 'sag1v' };

logThis.apply(myObj);

Question #5

const logThis = () => {
  console.log(this);
};

const myObj = { name: 'sag1v' };

logThis.apply(myObj);

Question #6

function logThis() {
  console.log(this);
}

const someObj = new logThis();

Question #7

function logThis() {
  'use strict';
  console.log(this);
}

function myFunc() {
  logThis();
}

const someObj = new myFunc();

Question #8

function logThis() {
  console.log(this);
}

class myClass {
  logThat() {
    logThis();
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Question #9

function logThis() {
  console.log(this);
}

class myClass {
  logThat() {
    logThis.call(this);
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Question #10

class myClass {
  logThis = () => {
    console.log(this);
  };
}

const myObj = { name: 'sagiv' };

const myClassInstance = new myClass();
myClassInstance.logThis.call(myObj);

Bonus questions

Question #11

function logThis() {
  console.log(this);
}

const btn = document.getElementById('btn');
btn.addEventListener('click', logThis);

Question #12

const logThis = () => {
  console.log(this);
};

const btn = document.getElementById('btn');
btn.addEventListener('click', logThis);

Question #13

class myClass {
  logThat() {
    function logThis() {
      console.log(this);
    }
    logThis();
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Answers

Answer #1

function logThis() {
  console.log(this);
}

const myObj = {
  logThis,
};

myObj.logThis();

Result - myObj.
Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - No.
Was logThis called as an object method? - Yes, myObj is left to the dot.

Answer #2

function logThis() {
  console.log(this);
}

const myObj = {
  foo: function () {
    logThis();
  },
};

myObj.foo();

Result - window.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - No.
Was logThis called as an object method? - No.
Is strict mode on? - No.
default case - window (or global).

Answer #3

const logThis = () => {
  console.log(this);
};

const myObj = {
  foo: logThis,
};

myObj.foo();

Result - window.

Explanation:

Is logThis an arrow function? - Yes, whatever this set in the wrapping context. In this case the wrapping context is the “Global execution context” which inside it this refers to the window / global object.

Answer #4

function logThis() {
  console.log(this);
}

const myObj = { name: 'sag1v' };

logThis.apply(myObj);

Result - myObj.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - Yeas, whatever passed in as the first argument - myObj in this case.

Answer #5

const logThis = () => {
  console.log(this);
};

const myObj = { name: 'sag1v' };

logThis.apply(myObj);

Result - window.

Explanation:

Is logThis an arrow function? - Yes, whatever this set in the wrapping context. In this case the wrapping context is the “Global execution context” which inside it this refers to the window / global object.

Answer #6

function logThis() {
  console.log(this);
}

const someObj = new logThis();

Result - The object created by logThis.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - Yes, then this is an auto created object inside the function.

Answer #7

function logThis() {
  'use strict';
  console.log(this);
}

function myFunc() {
  logThis();
}

const someObj = new myFunc();

Result - undefined.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - No.
Was logThis called as an object method? - No.
Is strict mode on? - Yes, this is undefined.

Answer #8

function logThis() {
  console.log(this);
}

class myClass {
  logThat() {
    logThis();
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Result - window.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - No.
Was logThis called as an object method? - No.
Is strict mode on? - No.
default case - window (or global).

Answer #9

function logThis() {
  console.log(this);
}

class myClass {
  logThat() {
    logThis.call(this);
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Result - The object created by myClass.

Explanation:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - Yes, whatever passed in as first argument. OK, but we are passing this! what is this refers to inside the logThat execution context? Lets check:
- Is logThat an arrow function? - No.
- Was logThat called with new? - No.
- Was logThat called with call / apply / bind? - No.
- Was logThat called as an object method? - Yes, this is the object left to the dot - The auto created object inside myClass in this case.

Answer #10

class myClass {
  logThis = () => {
    console.log(this);
  };
}

const myObj = { name: 'sagiv' };

const myClassInstance = new myClass();
myClassInstance.logThis.call(myObj);

Result - The object created by myClass.

Explanation:

Is logThis an arrow function? - Yes, this refers to whatever the wrapping context set it, myClass in this case. Lets check what this refers to in the wrapping context:
- Is myClass an arrow function? - No.
- Was myClass called with new? - Yes, this refers to the newly created object (the instance).

note that we are using class fields which is a proposal currently in stage 3

Answer #11

function logThis() {
  console.log(this);
}

const btn = document.getElementById('btn');
btn.addEventListener('click', logThis);

Result - The btn element.

Explanation:
This is a tricky question because we never talked about event handlers attached to DOM elements. 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 btn object. We can look at it as if we did btn.click() or even btn.logThis(). 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

Now lets walk through the flow:

Is logThis an arrow function? - No.
Was logThis called with new? - No.
Was logThis called with call / apply / bind? - No.
Was logThis called as an object method? - Yes (sort of), in our case btn is left to the dot.

Answer #12

const logThis = () => {
  console.log(this);
};

const btn = document.getElementById('btn');
btn.addEventListener('click', logThis);

Result - window.

Explanation

Is logThis an arrow function? - Yes, whatever this set in the wrapping context. In this case the wrapping context is the “Global execution context” which inside it this refers to the window / global object.

Answer #13

class myClass {
  logThat() {
    function logThis() {
      console.log(this);
    }
    logThis();
  }
}

const myClassInstance = new myClass();
myClassInstance.logThat();

Result - undefined

Explanation:

You might expected to get the window object here (similar to question #8) but pay attention to this quote from MDN:

Note: Classes are always strict mode code. Calling methods with an undefined this will throw an error.

So basically we created the logThis function with the strict mod rules, which means we fallback to undefined and not the window/global object.

Wrapping up

We now understand that the assignment of this can be both dynamic and static (lexical).

Arrow functions will make it static and won’t even bother to mutate this at all. which means we will need to understand what this was set to in the wrapping execution context.
Plain Functions will make it dynamically, meaning it depends on how the function was invoked.

It may look intimidating and complex now, you probably thinking how would you remember the flow chart. Well you don’t need to, you can save or print this flow-chart or maybe even make your own. Every time you need to know what this refers to in your code just look at it and start going through the conditions. Rest assure, you will need to look at this flow-chart less and less as time goes by.

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). 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

Answering Stack Overflow questions can make you a better programmer

Sat, 29 Jun 2019 00:00:00 GMT

Why should I bother?

Why should we bother ourselves to try and solve other people’s challenges? We have our own challenges and sometimes are up against a tight deadline. I’m often asked this by friends and peers, so here is a list I made of the reasons that motivate me to answer Stack Overflow questions (not in a particular order):

The Motivation List

Points, Credit, Prestige
Kindness, giving back to the community
Gain experience with real world challenges
Keep up with the race and stay ahead of the game
Learning new things “by mistake”
Improve tech communication skills
Improve English skills (as a second language)
Document your solutions

I’m mostly mentioning Stack Overflow here because I think it’s the most comfortable platform to share knowledge, but everything I write here is relevant to any other platform.

Points, Credit & Prestige

Well, I wanted to start with this one because it’s kind of “The elephant in the room”. Most of us like getting credit for the things we do and who doesn’t LOVE points and ratings? I sure do! So yeah, I think it’s a motivation, although likely the most selfish item on my list. Is it at the top of the list? Nope. Read on and you may realize that it’s actually the least rewarding one (but still, rewarding).

Kindness and giving back to the community

OK, it’s a cliche. I know! But it can’t be helped, in most cases when we help someone it makes us feel good and satisfied. I gain so much knowledge from the “internet” (which is basically a bunch of people that help me whether they know it or not), so it’s only natural to want to give something back.

As a developer, Stack Overflow is and still is one of the best tools I have. “Giving back to the community” may be a cliche but this is the foundation stones which our community (should I write society?) is built upon. So if you have the chance and the ability, Give Back To The Community, do it with kindness and respect. And eventually you’ll find that what can be a small effort on your end, can have a big impact for the person sitting on the other side.

You may notice that this item on my motivation list is the only “none 100% selfish” motivation, I mean this is the only motivation that addresses the actual benefits gained by others, and not myself.

Gain experience with real world challenges

Consider the following scenario: You are learning a new language / technology / feature / design pattern, you have probably been watching some online courses and following some tutorials. I would even reckon, most if not all of them, provide simple examples under controlled laboratory conditions. But alas, none of us has the privilege to work under these conditions, we live in the real world.

The great thing about trying to answer questions on Stack Overflow is that you accept a ”real world” challenge.

As a beginner to the subject, you may not be able to provide a high-quality answer fast enough before the coveted great shiny check-mark was clicked and another answer was marked as accepted. That’s OK, though we do love points (as stated above) we are not here just for them, we also want to gain some experience. Rest assured, you have already gained experience - not only with a real world problem but we have also been lucky enough to see the solution.

We also gained experience with debugging, experience with solving (or trying to solve) hard and complex problems. Maybe the problem wasn’t that hard after all, but there wasn’t enough information provided by the OP (Original Poster), so you gained the experience of asking the right questions to lead the OP to a “purified” version of the problem, cleaning up the noise and revealing the exact and accurate problem the OP was really facing. This is a huge value gained as a problem-solver, it’s beyond learning a new feature or a language, this is you becoming a better engineer.

I consider this as a bit of a hack, in a “normal” way, we gain experience through time (x years of experience). So basically experience is measured like

skill.exp = skill.handsOn * skill.numberOfYears;

And here we are kind of fast-tracking our hands-on experience through multi-threading, and not from our actual day job. So we are basically gaining the experience of others, and we do it in a relatively short period of time - the power of concurrency (we’re scaling our skill set).

Keep up with the race and stay ahead of the game

As opposed to the previous item on the list (which mostly addressed beginners) this one is mostly relevant for experienced developers. As an experienced developer you probably want to keep up with all the new stuff that coming out, or maybe you want to be that go-to person when people need help with new stuff. Maybe the tech you are working with isn’t the newest thing out there or maybe the version is a bit outdated. Answering questions on Stack Overflow may help you keep up with new technologies as they emerge, and sharpen your skills, enabling you to gain experience with that new feature that just came out last month.

Learning new things “by mistake”

Sometimes when you are trying to answer a question, you’ll notice that the OP (Original Poster) is using a stack or a library you are not experienced with. I mean, you know the tech the OP (Original Poster) is using, but there is a cool library or feature you never tried. In order to help, you may need to read the basics and look through the DOCS or maybe even try an API you never tried. This is awesome, because you just learned a new thing, and learning is part of our lives as developers. And maybe this new thing you just learned may even end up in one of your next projects. Who knows? ¯_(ツ)_/¯

Improve tech communication skills

One of the most important skills for developers is the “tech communication skill”, it allows you to articulate a problem or a solution which the other side (other team members) can easily understand. The ability to execute something that “lives” in your head is hard enough, but to explain it to others so they can be part of the operation… that’s a skill, a great skill to have on your tool-belt. To be able to write a high quality answer (or question, by the way) will require you to “stretch” that skill, this will let you enhance it. If there is one common thing for all of the best answers (and questions!) on Stack Overflow is that they are all well-phrased and the author managed to easily convey their idea to the reader. Some use humor, others use analogies and some use dry facts, it doesn’t matter as long as the reader gets the idea.

Improve English skills (as a second language)

Well this one is very personal and maybe considered as a niche, but English may not be your native language, well it’s not my native language and you probably already picked that up :smirk: ). With English being the universal language of technologists around the globe, and not all are born native speakers, this is a good way to gain confidence in your English skills, and can ultimately carry over to getting involved in others ways - such as contributing code or documentation to open source projects.

Document your solutions

You have taken the time to write great and useful solutions, why not document and preserve them somewhere? Stack Overflow can be a great place to store your solutions, you get a free space AND a great searching tool to track them later, you can basically see it as your own personal wiki. Another cool thing about it is that you can use your Stack Overflow profile page as a “portfolio of case studies”. I mean attaching it to a CV or including it in your LinkedIn account gives future recruiters a chance to see how you approach problems, and how you communicate solutions with others. Not to mention that it’s always good to be perceived as a person who helps others. :smile:

Summing it up

As you can see, there are a lot of reasons that should motivate you to be active as a Stack Overflow user (or any other similar platform). While some are for your own personal benefit and some can benefit your environment, all of them are eventually rewarding and satisfying. With that said, make sure it doesn’t interrupt your job or daily tasks. What works for me is to allocate a specific time for that within my free time and make sure I don’t exceed it.

I hope this was a good read and if you have any more “motivation items” to add to the list or any feedback please share, I would love to read it. 🤓

(This is a post published on my blog at debuggr.io. You can read it online here.)

React Micro Frontends

Sat, 17 Nov 2018 00:00:00 GMT

In this article / tutorial we will build a very basic react “widget” (a Counter!) and a very basic react application.we will see what problems we face when we try to interact with the two applications and how ReactDOM.render API help us to pass data in and out the applications while keeping the great unidirectional flow.

Note: you can implement this with any view framework / library, I just chose to do it with 2 react applications because i mostly work with react, but you can pass and get data from a react app with angular / vue / jQuery or vanilla JS.it doesn’t matter.

This is a followup article for this tweet

https://x.com/sag1v/status/1059579044826615808

This may address only specific use cases, like already existing applications or mini applications that you can’t or won’t rewrite, or stand-alone application which you need to provide to others to implement on their websites and you want to provide an API to interact with your application.

Lets Code

To make it easy to start and not waste time on building the “widget” and main application, i published a repository that will save you the time and hassle.

This repo holds 2 folders:

main-app (the main application project)
counter-app (our counter widget project)

Both of them built using create-react-app (because it’s easy, it’s fast and it just works)

Note that you don’t have to do it with create-react-app, you may already have a js build system running on your existing application. You may want to read Add React to a Website from the DOCS

Clone

clone the repository to your local drive

git clone https://github.com/sag1v/react-external-integration-starter.git

Install And Run

main-app

cd main-app
npm install
npm start

counter-app

cd counter-app
npm install
npm start

You may have prompted with this message

? Something is already running on port 3000
Would you like to run the app on another port instead? (Y/n)

Just confirm with “y” and press enter.

If both applications are running fine, you should see something similar to this

main-app page

counter-app page

In our main-app there’s nothing special going on right now, but lets look at the counter-app

counter-app/src/Counter.js

class Counter extends Component {
  state = { count: this.props.initialCount || 0 };

  updateCount = (val) => () => {
    const { onCountUpdate } = this.props;
    this.setState(
      (state) => {
        const nextCount = state.count + val;
        return { count: nextCount };
      },
      () => onCountUpdate(this.state.count)
    );
  };

  render() {
    const { count } = this.state;
    const { title } = this.props;
    return (
      <div className="counter">
        <h3 className="title">{title}</h3>
        <div className="buttons">
          <button onClick={this.updateCount(1)}>+</button>
          <span className="count"> {count} </span>
          <button onClick={this.updateCount(-1)}>-</button>
        </div>
      </div>
    );
  }
}

counter-app/src/index.js

const el = document.getElementById('counter-app');
ReactDOM.render(<Counter />, el);

As you can see, there’s nothing fancy here, just a counter with 2 buttons. The only thing we want to focus on is our props. We want to be able to pass props from the outside, props like initialCount, onCountUpdate and title . This is easy when we are inside the context of the Counter react app, but we want to be able to do that outside of that, from a different application.

But before we solve our problem, lets understand what exactly is our problem first.lets render the Counter inside our main-app.

To do that, we will need to run a build of our Counter and include the bundled files of the counter-app in the index.html file of our main-app .

In your command line, make sure you are at the /counter-app folder and run

npm run build

This will generate the js and CSS files for production.
Note: for simplicity and ease, i tweaked the build process of the counter-app. Every time we run build, the generated files will be placed in: main-app/public/counter_dist

This will make it easier for us to see the changes to the code as we go, so we don’t need to manually copy and paste the files there.

If all went well you should see these files in your main-app folder:

-main-app
    -public
    -counter_dist
    -static
    -css
        react-counter.css
    -js
        react-counter.js

Now go to main-app/public/index.html

Make sure you include the CSS and JS files of the Counter, we also need to render a div with the counter-app id

<div id="counter-app"></div>

Your index.html should end up with something like this:

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <meta name="theme-color" content="#000000">
  <link rel="manifest" href="%PUBLIC_URL%/manifest.json">
  <title>React App</title>
  <!-- uncomment this line when you sure you have react-counter bundle in the counter_dist folder -->
  <link rel="stylesheet" href="counter_dist/static/css/react-counter.css">
</head>

<body>
  <noscript>
    You need to enable JavaScript to run this app.
  </noscript>
  <div id="counter-app"></div>
  <div id="root"></div>
  <!-- uncomment this line when you sure you have react-counter bundle in the counter_dist folder -->
  <script src="counter_dist/static/js/react-counter.js"></script>
</body>

</html>

And this is how our page should look like

So now we have both our main-app and Counter on the same page, but this is not what we wanted, we want the Counter inside the main-app. We could render the div of the counter-app inside our App component instead of just throwing it in the index.html file, but this won’t work.

In fact, lets see why it won’t work Remove this from index.html

<div id="counter-app"></div>

And move it to App.js (main-app/src/App.js)

class App extends Component {
  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <div id="counter-app"></div>
          <p>This is the main App.</p>
        </header>
      </div>
    );
  }
}

After you hit save, you can see the Counter is no longer displayed on our screen. In fact we have an invariant 200 error in console with a link to https://react.dev/errors/200

Target container is not a DOM element.

In other words, the div container for the counter-app is not there.

But wait, didn’t we just render it inside our App.js? This message is coming from our Counter application, from these lines:

const el = document.getElementById('counter-app');
ReactDOM.render(<Counter />, el);

What happens here is that our Counter application is running before our main-app application, so App.js didn’t run yet and we didn’t pass a valid second argument to ReactDOM.render.

Our First Real Challenge

So this is the first challenge we need to solve, we want to control the order of the scripts or moreover the order of the function calls. Of course this is one of the oldest challenges we have in the JavaScript web world and some of the solutions to that are: modules, bundlers etc.

Our script tag is at the end of the body block but the problem here is that webpack is injecting the main-app scripts in run-time to the end of the body block as well. This is why we can’t run Counter after the main-app scripts.
We could hack around with the async / defer attributes of the <script/> tag but that won’t solve our problem, even if it did solve the ordering, it won’t solve our real problem: Getting data in and out of the Counter component and control it.

First Part Of The Solution

Maybe, instead of just running this code

const el = document.getElementById('counter-app');
ReactDOM.render(<Counter />, el);

We will wrap it inside a function, and expose it globally, this way, other applications can decide when to run it and will do it explicitly.

Before we dive in to the actual implementation, we also want to enable an un-mount of our widget. ReactDOM has another method just for that unmountComponentAtNode

So we need a reference to the counter-app container for both methods.

Lets modify our index.js of count-app to this:

window.ReactCounter = {
  mount: () => {
    const el = document.getElementById('counter-app');
    ReactDOM.render(<Counter />, el);
  },
  unmount: () => {
    const el = document.getElementById('counter-app');
    ReactDOM.unmountComponentAtNode(el);
  },
};

As you can see, we expose a global object ReactCounter with 2 methods:

mount
unmount

Both will use ReactDOM under the hood.

Now lets build counter-app with our command (make sure you are in /counter-app folder)

npm run build

If we refresh the page of main-app we won’t see the counter but we also won’t get an error, as we never tried to render to a none existing element. that’s a good sign! 👍

Now we can call our mount function inside App.js, lets do that after the first render of App.js with the componentDidMount life cycle method, this way we are sure the <div/> container for the counter-app is already rendered.

class App extends Component {

  componentDidMount(){
    window.ReactCounter.mount();
  }

  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <div id="counter-app"></div>
          <p>
            This is the main App.
          </p>
        </header>
      </div>
    );
  }
}

After you hit save you can see our counter below the react logo, INSIDE our App.js! 👊

We know we can un-mount it as well, so just for fun lets toggle it with a click on the react logo. Lets make these changes in our App.js

class App extends Component {
  state = { showCounter: false };

  componentDidUpdate(prevProps, prevState) {
    const { showCounter } = this.state;
    if (prevState.showCounter !== showCounter) {
      if (showCounter) {
        window.ReactCounter.mount();
      } else {
        window.ReactCounter.unmount();
      }
    }
  }

  toggleCounter = () => {
    this.setState(({ showCounter }) => {
      return { showCounter: !showCounter };
    });
  };

  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img
            onClick={this.toggleCounter}
            src={logo}
            className="App-logo"
            alt="logo"
          />
          <div id="counter-app"></div>
          <p>This is the main App.</p>
        </header>
      </div>
    );
  }
}

As you can see, we added a state with a showCounter key. we replaced componentDidMount with componentDidUpdate so we can react to changes of the state, and we conditionally call ReactCounter.mount or ReactCounter.unmount based on showCounter. We also added a toggleCounter handler and attached it to the onClick prop of the logo’s <img/> element.

You should end up with this

Passing props

While this is nice, we also want to pass data to our Counter, if we look at our mount function, there’s nothing stopping us from passing it parameters and allow it to pass parameters to the <Counter/> component. In counter-app/src/index.js you should change your code to this:

window.ReactCounter = {
  mount: (props) => {
    const el = document.getElementById('counter-app');
    ReactDOM.render(<Counter {...props} />, el);
  },
  unmount: () => {
    const el = document.getElementById('counter-app');
    ReactDOM.unmountComponentAtNode(el);
  },
};

After you build counter-app with npm run build you can go to main-app/src/App.js and pass an object props to mount.
I passed {title: ‘Whaaa! cool’}

componentDidUpdate(prevProps, prevState) {
  const { showCounter } = this.state;
  if (prevState.showCounter !== showCounter) {
    if(showCounter){
      window.ReactCounter.mount({title: 'Whaaa! cool'});
    } else{
      window.ReactCounter.unmount();
    }
  }
}

And this is how it looks like:

It’s like the render you know and love!

Now lets revisit a quote from my tweet above:

You can call ReactDOM.render multiple times. Not only that but it actually won’t re-mount the entire application, instead it will trigger a diffing…

Now, we know it won’t re-mount the entire application, that’s what ReactDOM.render and ReactDOM.unmountComponentAtNode are for, but what do I mean by “trigger a diffing”?

Well it’s like the render method of our class components in this case, when the life cycle render method is invoked, it will trigger the Reconciliation process. ReactDOM.render will do the same.

Lets put it to test, we can store the title value in the state of our App.js, change it with an <input/> and see if our Counter can get the updated values.

In our App.js we will change to this code:

class App extends Component {
  state = { showCounter: false, title: 'Whaaa! cool' };

  componentDidUpdate(prevProps, prevState) {
    const { showCounter, title } = this.state;
    const shouldUpdateCounter =
      prevState.showCounter !== showCounter || prevState.title !== title;
    if (shouldUpdateCounter) {
      if (showCounter) {
        window.ReactCounter.mount({ title });
      } else {
        window.ReactCounter.unmount();
      }
    }
  }

  toggleCounter = () => {
    this.setState(({ showCounter }) => {
      return { showCounter: !showCounter };
    });
  };

  onTitleChange = ({ target }) => {
    this.setState({ title: target.value });
  };

  render() {
    const { title } = this.state;
    return (
      <div className="App">
        <header className="App-header">
          <img
            onClick={this.toggleCounter}
            src={logo}
            className="App-logo"
            alt="logo"
          />
          <div id="counter-app"></div>
          <p>This is the main App.</p>
          <input value={title} onChange={this.onTitleChange} />
        </header>
      </div>
    );
  }
}

And this is how it should look like:

Get data back

Well, we also wanted to get data back from our widget, if you remember as part of our Counter API, we can pass onCountUpdate callback to get the current count. How can we pass it? if we can pass props as an object, nothing is stopping us from passing functions inside that object.

Lets add a div in our App.js that will show the current count. We will need to pass a handler to the Counter and store the current count in App.js‘s state as well.

Lets change App.js to this:

class App extends Component {
  state = {
    showCounter: false,
    title: 'Whaaa! cool',
    currentCount: 3,
  };

  componentDidUpdate(prevProps, prevState) {
    const { showCounter, title, currentCount } = this.state;
    const shouldUpdateCounter =
      prevState.showCounter !== showCounter || prevState.title !== title;

    if (shouldUpdateCounter) {
      if (showCounter) {
        const counterProps = {
          title,
          initialCount: currentCount,
          onCountUpdate: this.onCountUpdate,
        };
        window.ReactCounter.mount(counterProps);
      } else {
        window.ReactCounter.unmount();
      }
    }
  }

  toggleCounter = () => {
    this.setState(({ showCounter }) => {
      return { showCounter: !showCounter };
    });
  };

  onTitleChange = ({ target }) => {
    this.setState({ title: target.value });
  };

  onCountUpdate = (currentCount) => {
    this.setState({ currentCount });
  };

  render() {
    const { title, currentCount } = this.state;
    return (
      <div className="App">
        <header className="App-header">
          <img
            onClick={this.toggleCounter}
            src={logo}
            className="App-logo"
            alt="logo"
          />
          <div id="counter-app"></div>
          <p>This is the main App.</p>
          <div>{`The count is ${currentCount}`}</div>
          <input value={title} onChange={this.onTitleChange} />
        </header>
      </div>
    );
  }
}

Note that we also pass the initialCount prop with a value of 3 to the Counter. And this is the result:

We did it! we are communicating with an “isolated” react application, we pass data to it and able to get data back from it. But we are not done yet! we may have solved our general challenge but if we think about it, we still have 2 major issues, we can’t create multiple instances and our code is imperative as hell. Let’s make it more “react’ish”.

The multiple instances challenge

Looking at our Counter’s API in index.js:

window.ReactCounter = {
  mount: (props) => {
    const el = document.getElementById('counter-app');
    ReactDOM.render(<Counter {...props} />, el);
  },
  unmount: () => {
    const el = document.getElementById('counter-app');
    ReactDOM.unmountComponentAtNode(el);
  },
};

We can see that we have a problem, the Counter forces us to use the same id for its container. If we think about it, this is not the Counter’s responsibility to decide what kind of container to render itself, and maybe it should not even do the job of querying the DOM to get the container. Maybe the Counter should just get a reference to the element? Lets try it.

In counter-app/src/index.js change to this code: don’t forget to run npm run build after the change.

window.ReactCounter = {
  mount: (props, container) => {
    ReactDOM.render(<Counter {...props} />, container);
  },
  unmount: (container) => {
    ReactDOM.unmountComponentAtNode(container);
  },
};

In main-app/src/App.js change to this code: note how we omit the counter-app id attribute from our div

class App extends Component {
  state = {
    showCounter: false,
    title: 'Whaaa! cool',
    currentCount: 3,
  };

  // create refs so we can pass the element to mount and unmount
  counterOneRef = React.createRef();
  counterTwoRef = React.createRef();

  componentDidMount() {
    // just test another instance of the Counter
    window.ReactCounter.mount(
      { title: 'counter two' },
      this.counterTwoRef.current
    );
  }

  componentDidUpdate(prevProps, prevState) {
    const { showCounter, title, currentCount } = this.state;
    const shouldUpdateCounter =
      prevState.showCounter !== showCounter || prevState.title !== title;

    if (shouldUpdateCounter) {
      if (showCounter) {
        const counterProps = {
          title,
          initialCount: currentCount,
          onCountUpdate: this.onCountUpdate,
        };
        window.ReactCounter.mount(counterProps, this.counterOneRef.current);
      } else {
        window.ReactCounter.unmount(this.counterOneRef.current);
      }
    }
  }

  toggleCounter = () => {
    this.setState(({ showCounter }) => {
      return { showCounter: !showCounter };
    });
  };

  onTitleChange = ({ target }) => {
    this.setState({ title: target.value });
  };

  onCountUpdate = (currentCount) => {
    this.setState({ currentCount });
  };

  render() {
    const { title, currentCount } = this.state;
    return (
      <div className="App">
        <header className="App-header">
          <div ref={this.counterTwoRef}></div>
          <img
            onClick={this.toggleCounter}
            src={logo}
            className="App-logo"
            alt="logo"
          />
          <div ref={this.counterOneRef}></div>
          <p>This is the main App.</p>
          <div>{`The count is ${currentCount}`}</div>
          <input value={title} onChange={this.onTitleChange} />
        </header>
      </div>
    );
  }
}

You should see a similar result to this:

What we did here is that we passed a reference of the actual element to the mount and unmount methods, we could instead pass a selector like .myClass or #myId and use document.querySelector, but i think passing the element itself is respecting the separation of concerns in a better way.

Yay, we now have multiple instances support! 💪

The imperative code challenge

One of the core concepts and methodology of react is a Declarative way to write UI’s, we achieve that with Components.
If we look at our code in App.js we see a mess, its an imperative hell (i remind you that this is only a simple Counter and not a real world app!).
What if we wrap this entire code in a reusable component, lets say we call it… <ReactCounter /> so its easy to distinguish it from the real Counter.js.

Lets see how such component would look like: You can create the new file main-app/src/ReactCounter.js

import React, { PureComponent } from 'react';

class ReactCounter extends PureComponent {
  // create a ref so we can pass the element to mount and unmount
  counterRef = React.createRef();

  componentDidMount() {
    // initial render with props
    window.ReactCounter.mount(this.props, this.counterRef.current);
  }

  componentDidUpdate(prevProps) {
    if (prevProps !== this.props) {
      window.ReactCounter.mount(this.props, this.counterRef.current);
    }
  }

  componentWillUnmount() {
    window.ReactCounter.unmount(this.counterRef.current);
  }

  render() {
    return <div ref={this.counterRef}></div>;
  }
}

export default ReactCounter;

Look how clean and concise it is.
note that we are using a React. PureComponent here, you may need a regular React. Component.

Lets look on how App.js is using this new component:
Don’t forget to import the component

///...
import ReactCounter from ‘./ReactCounter’
//...

class App extends Component {
  state = {
    showCounter: false,
    title: 'Whaaa! cool',
    currentCount: 3
  }

  toggleCounter = () => {
      this.setState(({ showCounter }) => {
          return { showCounter: !showCounter }
      });
  }

  onTitleChange = ({ target }) => {
      this.setState({ title: target.value })
  }

  onCountUpdate = currentCount => {
      this.setState({ currentCount })
  }

  render() {
    const { title, currentCount, showCounter } = this.state;
    return (
      <div className="App">
        <header className="App-header">
          <ReactCounter title="counter two" />
          <img
            onClick={this.toggleCounter}
            src={logo}
            className="App-logo"
            alt="logo"
          />
          {
            showCounter && (
              <ReactCounter
                title={title}
                initialCount={currentCount}
                onCountUpdate={this.onCountUpdate}
              />
            )
          }
          <p>
            This is the main App.
          </p>
          <div>{`The count is ${currentCount}`}</div>
          <input value={title} onChange={this.onTitleChange} />
        </header>
      </div>
    );
  }
}

Now this looks much better, we can’t even tell that ReactCounter is an external stand-alone application, it looks and behave like any other component.

Of course the page should look the same as before, we just improved our code.

Wrapping up

We observed on how we can interact with a separate and isolated react application, i chose to use another react application to interact with it but this is not limited only to react, you can call our mount function and pass it the props object with any framework you work with, these are just JavaScript functions.

As i mentioned at the top, this may solve a specific problem, this is not the “normal” way we write our applications, but it’s good to know we can do that when we need it thanks to the flexible and solid API of react and ReactDOM.

Thank you for your patience, I hope it helped you in some way.
If you have any comments / suggestions or questions, please feel free to reach me at twitter @sag1v. 🤓

I would love to see some examples of this approach with other frameworks, take the bundled files of the counter-app and interact with other frameworks / libraries.

References

It’s highly recommended to read Integrating with Other View Libraries from the react DOCS.

(This is a post published on my blog at debuggr.io. You can read it online here.)

JavaScript == VS === The truth

Sat, 11 Aug 2018 00:00:00 GMT

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.

(This is a post published on my blog at debuggr.io. You can read it online here.)

Redux is dead! long live react's context API(?)

Wed, 25 Jul 2018 00:00:00 GMT

Well, do not let the title mislead you, it is only meant to lure you in :) Redux is not dead. on the contrary it is very alive and is far from being irrelevant.

So what are you doing here?

This post is meant to be a “counter attack” against all of the blog-posts / articles / tutorials / tweets / stories that sprang up like mushrooms after the rain when react v16.3 released and the announce about the New Context API. And shockingly this is not a passing trend, people still write and post about this match-up.

Posts that shared a similar title like this post or something like: “Redux Vs React’s new context API”

Spoiler alert!!! Most of them will tell you it depends on how big is your app.

I have nothing against any of the authors of these posts, but I do think this is important enough to write about.

I think this is one of the most misleading and confusing topics for developers that are either new to react or new to Redux.
When people start to learn react they get flooded with topics like npm, babel, ES6, webpack, node.js, express, Redux and the list goes on.

Not only are these topics not mandatory for learning react but also may lead to confusion, especially if it leads them to think that Redux is just a way to pass data down to react’s child components and now there’s a better way, called the new react context API.

It is impossible to compare the two, you know what? let’s try.

Trial #1 — `Redux` Vs The new context API

Redux is a state-manager, it helps you manage a big JavaScript object that holds the state of your application. It’s doing it with style though, in a beautiful functional way with pure functions (reducers), plain and serializable objects as actions, great middle-ware support and an amazing pub/sub architecture. By the way, Redux has nothing to do with react. OK, one of the authors of Redux is working at facebook and surprisingly at the react team. but really, Redux has no opinions about which framework or library you should use. You can use it with AngularJS or Angular10, you can use it with jQuery or vanilla JS, you can even use it with react! Its “just” a javascript state-manager library. Actually let’s quote the docs: “Redux is a predictable state container for JavaScript apps.”
The new context API is not even a new feature in react, it was there the whole time and it just got a new face. Well a new Application-Program-Interface. Think of it for a moment, if it’s not new why people compare it now? (OK maybe it was a taboo :) ) Don’t get me wrong, it’s a great improvement for the API (using the render props) and a very important feature, but it’s not a new feature. It allows you to expose data as a Provider (remember this word, we will bump into it again later on) and allows you as a Consumer to get a hold of this data. Now get this, no matter how deeply nested the Consumer is as a child component it has access to the Provider’s data as if it is connected to it. This means you can pass data from a parent to a great-grandchild without the use of props. It enables you to dodge the bullet of prop drilling, and the best thing about the new context API is that you wont pay the price of magical data that popped out from nowhere (well, mostly). So basically, react’s context feature is really just another way to pass data down to children.

Note: if you’re tired of prop-drilling don’t forget you don’t have to encapsulate child components inside their parents, you can go for the Containment pattern and just render the {children}.

Well we are trying to compare a “State manager for JavaScript applications” with yet another way of react to pass data from a parent component down to it’s children.

We are trying to compare a Car with a Wheel, Impossible to compare the two.

Provider, Consumer, passing down data no matter how deeply nested, connect them together…. Did we actually want to compare react-redux with the new context API and not Redux itself?

Well lets try…

Trial #2 — react-redux Vs The new context API

react-redux is an abstraction, a way to bind your Redux store to react. Let’s remember what we need to do in order to bind Redux to react without react-redux. in order to bind Redux to react you need to do couple of things:

The first is not really directly related to react, I’m talking about the subscription to the store with the store.subscribe() method, this is done inside a Container component.
The second is to pass the store object down the tree as a prop up until you get to the Container component that holds the subscription logic (it needs the actual store object to run methods like subscribe, dispatch etc…) WoooHaaa, prop drilling!

OK, so basically react-redux is doing all of this for us (and probably doing a better job than we would do performance wise).

The connect HOC
A High Order Component that creates the Container Component for us with all the subscription logic + great functions to pass portions of the store and action-creators to its children as props (mapStateToProps & mapDispatchToProps).
Provider
A Component that will hold and pass down our store.

WAIT! how exactly the Provider and the connect HOC are connected? how is the data being passed from the Provider to the Container?

This is where react’s context API plays a big and important role, The Provider is exposing the store as a context. The Container created by connect is grabbing this context. Yes, via the context API.

So lets say that react’s context feature is like 10% - 20% of the logic react-redux is doing for us.

We are trying to compare a 4-Wheel-Drive with a Wheel, Impossible to compare the two.

So bottom line, don’t try to compare the new context API with Redux or react-redux. it’s just wrong, and misleading others. If new comers are wrongly refer to Redux as react-redux or vise versa, don’t do the same in your articles, posts, tweets. it will just keep them from learning the real differences.

(This is a post published on my blog at debuggr.io. You can read it online here.)

debuggr.io

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

What is actually being lost

Why this matters for AI itself

The privatization problem

One rough direction worth thinking about

The real unsolved piece

Where does this land

Stop Asking AI for Answers - Start Shipping Fixes

Why this was not approachable before AI

What AI unlocked

Gain experience with real world challenges

Keep up with the race and stay ahead of the game

Learning new things by mistake

Improve tech communication skills

Document your solutions

Kindness, giving back to the community

Points, credit, prestige

A simple weekly loop

Closing

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

The 10x Productivity Paradox

The “Keep PRs Small” Band-Aid

The Obvious Suspect: AI Reviewers

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

How We Make Peace With Third-Party Code

The Rabbit Hole Deepens

The Uncomfortable Questions

What This Means for the Future

The Next Bottleneck

Where Do We Go From Here?

Final Thoughts

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

The Problem: AI Agents Don’t Know Your Organization

The Root Cause: Context is King

Our Solution: Teaching AI Agents About Our Organization

1. Comprehensive Documentation Layer

2. Living Project Catalog

3. MCP Server: The Bridge Between AI and Infrastructure

How It Works in Practice

The Impact

The Bigger Picture: Every Organization Needs This

Key Takeaways

Getting Started

React - setState is not a function

Prerequisite -

The problem

Possible solutions

#1 bind

#2 Arrow function

Wrapping up

React - Cannot read property 'map' of undefined

The problem

Possible solutions

#1 Initial value

#2 Conditional rendering

#2.5 Inline conditional rendering

Wrapping up

JavaScript - Closure in depth

Stateful functions

Execution context

Global execution context

Lexical Scope

Optimizations

Wrapping up

JavaScript - The prototype chain in depth

Our Goal

Objects

Object Literal

Object.create

Automating

Factory Functions

OLOO - Objects Linked To Other Objects

️️⚠️ Note

The new operator - A.K.A Constructor function

What is a function really?

The prototype property

Invoking with the new operator

Lets walk through that code (execution phase)

Class

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

Invoking with the `new` operator