Forem: Abhishek I

React 19.2’s : Because ‘display: none’ Shouldn’t Mean ‘Memory Loss’

Abhishek I — Mon, 27 Oct 2025 10:02:45 +0000

React 19.2 just dropped a feature that’s small in appearance but massive in impact, the new <Activity /> component.

Think of it as giving your components the power to take a nap instead of being completely wiped out.

Up until now, when you wanted to hide or show parts of your UI, you’d usually reach for conditional rendering. It works, sure, but here’s the gotcha: once a component unmounts, everything inside it, its state, effects, and DOM, gets obliterated. When you bring it back, React rebuilds the whole thing from scratch.

Enter <Activity />.

Instead of unmounting, React can now pause a component, cleaning up its side effects while keeping its DOM and state safely tucked away in memory until you need it again.

// Before
{activeView === "list" && (
          <NotesList
            notes={notes}
            onEdit={handleEdit}
            onSelectNote={handleEdit}
          />
        )
    }

 // After 
 <Activity mode={activeView === "list" ? "visible" : "hidden"}>
          <NotesList 
            notes={notes}
            onEdit={handleEdit}
            onSelectNote={handleEdit}
          />
 </Activity>

In React 19.2, Activity supports two modes: visible and hidden.

hidden: hides the children, unmounts effects, and defers all updates until React has nothing left to work on.
visible: shows the children, mounts effects, and allows updates to be processed normally.

This means you can pre-render and keep rendering hidden parts of the app without impacting the performance of anything visible on screen.

One Example to Rule Them All: A “Remembering” Note Editor

Let’s see <Activity /> in action with a simple two-view notes app.

Our app has:

A Notes List view
A Note Editor view

…and you can switch between them using buttons.

Inside the editor, we have:

A textarea where users can type drafts (browser-managed DOM state).
A “Show Details” toggle (React-managed state).

Now, in a typical React setup using conditional rendering, as soon as you hide the editor, both the draft text and toggle state vanish into the void. When you switch back, everything resets, not ideal.

What’s Different Now

With <Activity />, React doesn’t destroy the editor when you hide it, it just applies a display: none.

That means:

Your React state (showDetails) stays alive.
Your DOM state (the text you typed) stays exactly where you left it.

When you return, your note, toggle, and even your cursor position are waiting for you, no re-renders, no lost progress.

Why This Changes the Game

<Activity /> brings a new middle ground: “keep it alive, but deactivate it.”

It’s the perfect combo, your hidden components don’t hog performance, yet they don’t restart every time you bring them back.

This opens up a bunch of UX upgrades for:

Modals or drawers that reopen with user input still intact.
Multi-step forms that remember your progress.
Tabbed or toggled layouts that switch instantly without a re-render hit.

It’s one of those upgrades that you don’t realize you’ve been missing until you try it.

Wrapping Up: Hidden, But Not Forgotten

React 19.2’s <Activity /> isn’t just another quality-of-life tweak, it’s a quiet redefinition of how React handles component lifecycles.

It softens the hard boundary between “mounted” and “unmounted,” giving developers finer control over what stays alive behind the curtain.

Hidden components are no longer “gone”, they’re simply napping.

And with that, React takes another step toward UIs that feel less like web pages, and more like living, breathing apps that remember you.

Find the complete documentation here:https://react.dev/
Blog post for React 19.2 https://react.dev/blog/2025/10/01/react-19-2

BOMs, But Make It Visual: Level Up Your Product Game

Abhishek I — Sat, 04 Oct 2025 05:50:10 +0000

The Spreadsheet Struggle

Imagine managing a product with hundreds of components - a smartphone, a car engine, or even a simple pair of earbuds. Most teams start with Excel: endless rows of part numbers, suppliers, and costs. At first, it works. But as the product grows into multi-level assemblies (parts inside subassemblies, inside bigger assemblies), the spreadsheet becomes a nightmare to maintain. One missed update, one wrong formula, and suddenly… chaos mode activated.

Frontend to the Rescue: Why Traditional BOM Management Falls Short

Traditional methods often rely on spreadsheets or siloed PLM/ERP systems, which create:

Errors & Duplicates - Manual updates are prone to mistakes
Data Silos - Engineers, procurement, and quality teams work in isolation
Limited Insights - Hard to spot cost drivers or compliance risks quickly
Complexity Blind Spots - Multi-level hierarchies flattened into rows

Here’s the key: frontend is not just about landing pages - it’s the whole interactive experience. Modern frameworks like React, Angular, and Vue turn static BOM data into a dynamic environment where teams can explore, analyze, and act in real time.

How Frontend Tech Transforms BOMs

Modern web technologies allow you to visualize BOMs like never before:

Tree Structures & Expandable Views – Click to drill down assemblies into subassemblies and parts
Dynamic Filtering & Search – Quickly locate suppliers, costs, or lifecycle risks
Charts & Dashboards – Visualize cost distribution, supply risk, or inventory status in real time
Collaboration & Interactivity – Frontend frameworks make it easy to sync updates, comments, and approvals across teams

In short: your BOM goes from static spreadsheet to interactive decision-making platform.

Industrial Use Case: Wireless Earbuds

Traditional table:

Assembly	Part Number	Description	Supplier	Qty	Cost ($)	Lifecycle
Earbuds	EB-001	Left Earbud	In-house	1	20	Active
Earbuds	EB-002	Right Earbud	In-house	1	20	Active
Left Earbud	EB-101	Speaker Driver	ABC Audio	1	5	Active
Left Earbud	EB-102	Microphone	SoundTech	1	3	Active
Charging Case	EB-301	Battery	PowerCell	1	7	EOL soon
Charging Case	EB-302	USB-C Port	FastConnect	1	2	Active

Looks okay… but spotting risks? Big yikes.

With visualization:

Engineers see tree expansion (Earbuds → Left Earbud → Speaker)
Procurement sees a Pareto chart of cost contribution (battery = main $$$ culprit)
Compliance team spots “Battery supplier = EOL soon” #RedFlag

BOM, locked and loaded from boring list to collab beast.

Data Sources

BOM data typically comes from multiple systems across the product lifecycle:

CAD – Generates initial part lists from 3D models
PLM – Manages engineering BOMs, revisions, compliance
ERP – Captures supplier data, costs, inventory
Spreadsheets – Still hanging around in small orgs, but kinda sus for big ops

Data Structure

Core attributes – Part number, description, supplier, cost, quantity, lifecycle
Parent–child hierarchy – Products → Subassemblies → Components
Multi-level BOMs – Reflect real-world product complexity
Consistency is king – Unique IDs, parent–child links, standardized attributes

Architecture for BOM Visualization

Benefits of BOM Visualization

Faster Decision-Making – Spot risks at a glance
Cross-functional Collab – Engineers, buyers, managers on the same page
Error Reduction – Visual hierarchy = fewer oopsies
Version Tracking – Compare BOM revisions visually

Closing Thoughts

BOM visualization transforms the way teams understand, manage, and optimize products. Instead of drowning in spreadsheets, companies get living, interactive dashboards that scale with product complexity.

Whether you’re building earbuds or a jet engine, the principle is the same:

See the product not just as a list of parts, but as a connected digital model.

Source Code: Github
Try out on your own: Web App

That’s the real power of BOM visualization in modern industry.

From Static Forms to Dynamic Configurator: Our Journey in PLM

Abhishek I — Wed, 10 Sep 2025 17:03:44 +0000

Imagine you’re asked to build a product configuration form. At first glance, it sounds simple-pick a model, select a few options, and you’re done. But what if that product comes in _thousands_of possible combinations? Suddenly, your neat little dropdown turns into a nightmare of tangled logic and endless updates.

That’s the situation we found ourselves in. What began as a plain React form grew into a dynamic, rule-driven configurator that could scale gracefully and give users instant feedback. Here’s the story of how we got there.

Why Static Forms Fall Apart

Our first approach looked something like this:

<form>
  <label>Model</label>
  <select>
    <option>Model-A</option>
    <option>Model-B</option>
  </select>
  <button type="submit">Apply Configuration</button>
</form>

It worked for two options. But once complexity kicked in, the cracks showed:

Hardcoding overload – every new choice meant editing frontend code.
Validation lag – errors only appeared after hitting submit.
Scattered rules – logic was split between frontend and backend.
Scaling issues – hundreds of interdependent options were impossible to manage.

Clearly, this wasn’t sustainable.

The Pivot: Building Dynamically

We set four principles for the new system:

Schema-driven forms – UI should generate itself from a JSON schema.
Real-time validation – errors should appear as soon as a wrong option is selected.
Centralized business logic – validation rules live in the backend, not duplicated in the frontend.
Visual previews – users should see results immediately, even in 3D where possible.

The stack:

React for the UI
@rjsf/core (React JSONSchema Form) for schema-based form generation
AJV for JSON Schema validation
Node.js for enforcing business rules and integrating with PLM systems
Three.js for interactive 3D previews

How It Fits Together

The frontend dynamically renders forms and handles simple checks. The backend enforces rules and returns either errors or a valid configuration. The preview then updates instantly.

JSON Schema: The Core

At the center is a schema like this:

{
  "title": "Product Configuration",
  "type": "object",
  "properties": {
    "model": { "type": "string", "enum": ["A", "B"] },
    "color": { "type": "string", "enum": ["Red", "Blue", "Green"] },
    "size": { "type": "string", "enum": ["Small", "Medium", "Large"] }
  },
  "required": ["model", "color"]
}

And the backend enforces rules cleanly:

app.post("/validate", (req, res) => {
  const { model, color } = req.body;
  if (model === "A" && color === "Green") {
    return res.status(400).json({ error: "Model A does not support Green" });
  }
  res.json({ success: true });
});

No duplication, no guesswork.

Frontend Implementation

With RJSF and AJV, the form almost builds itself:

import Form from "@rjsf/core";
import validator from "@rjsf/validator-ajv8";

const schema = { /* schema as above */ };

const App = () => {
  const handleSubmit = ({ formData }) => {
    console.log("Submitted:", formData);
    // Send to backend for validation
  };

  return (
    <Formschema={schema}
      validator={validator}
      onSubmit={handleSubmit}
    />
  );
};

export default App;

Custom UI tweaks and validation messages make it user-friendly while still fully dynamic.

The User Experience

Here’s what happens when someone configures a product:

They select: Model A, Color Red, Size Medium.
Local schema check passes.
The UI displays the message instantly.
Once valid, the live preview updates.

They select: Model C, Color Red

API call flags an error:

{ "error": "Model A does not support Green" }

Result: a smooth, guided workflow with minimal frustration.

Why This Approach Works

Scalable - handle thousands of options without rewriting the UI.
Maintainable - rules live in one place, the backend.
Cross-platform - the same schema can drive web, mobile, or desktop.
User-friendly - instant validation and previews reduce trial-and-error.

Wrapping Up

We went from static, brittle forms to a flexible, schema-driven configurator that’s easier to maintain and far more enjoyable for users.

If your forms are drowning in hardcoded logic, it might be time to let schemas and centralized rules do the heavy lifting.

“Curious to try it out? Explore the project on GitHub Contributions and feedback welcome!”

Have you dealt with similar form chaos? How did you approach validation and scaling? Share your thoughts-I’d love to swap ideas.