DEV Community: abhilashlr

Stop Hardcoding Dashboards: Build JSON-Driven Analytics Widgets Instead

abhilashlr — Sat, 07 Mar 2026 06:10:41 +0000

Analytics dashboards usually start simple.

A chart here. A table there. Maybe a couple of metrics.

But over time, dashboards grow into something far more complex:
different widget types, customizable titles and descriptions, layout
rules, conditional rendering, and feature flags.

If each widget is hardcoded in the UI, the dashboard slowly turns into a
collection of one-off components that are difficult to maintain.

Recently, we solved this problem by building an analytics widget system
that combines composable React components with a JSON-driven
configuration layer.

The result: dashboards where widgets are defined by configuration
instead of hardcoded UI.

⚠️ The Problem with Hardcoded Dashboards

Many dashboards begin with a straightforward implementation.

<Dashboard>
  <RevenueChart />
  <ActiveUsersChart />
  <ErrorRateWidget />
</Dashboard>

This works fine at first, but the problems appear as dashboards evolve:

Every widget requires a dedicated component\
Layout and presentation logic get duplicated\
Titles and descriptions live inside UI code\
Small content changes require deployments\
Adding variations leads to component explosion

Eventually, the dashboard becomes tightly coupled to the frontend
codebase.

We wanted a system where widgets could be described declaratively
instead of implemented manually.

💡 The Core Idea: Configuration Over Components

Instead of hardcoding widgets in React, we describe them using a JSON
configuration.

Example:

{
  "id": "api_error_rate",
  "title": "API Error Rate",
  "description": "Error percentage in the last 24 hours",
  "type": "line-chart",
  "query": "errors_over_time",
  "timeRange": "24h"
}

This configuration contains everything required to render a widget.

The UI layer simply interprets the configuration and renders the
correct component.

This creates a clear separation:

Configuration → what should be shown\
Components → how it should be rendered

🧩 The Widget Renderer

At runtime, a renderer maps the configuration to the appropriate
component.

function WidgetRenderer({ config }) {
  const Component = widgetRegistry[config.type]

  return (
    <WidgetContainer
      title={config.title}
      description={config.description}
    >
      <Component config={config} />
    </WidgetContainer>
  )
}

🗂️ The Widget Registry

To support multiple widget types, we maintain a registry.

const widgetRegistry = {
  "line-chart": LineChartWidget,
  "bar-chart": BarChartWidget,
  "stat": StatWidget,
  "table": TableWidget
}

Adding a new widget type becomes straightforward:

Create the component\
Register it in the widget registry

No changes to the dashboard structure are required.

🧱 A Composable Widget Structure

Every widget follows a consistent layout:

Widget
 ├── Title
 ├── Description
 └── Content (chart / table / stat)

The container component handles:

layout and spacing\
titles and descriptions\
loading states\
error states\
consistent styling

This allows widgets to focus purely on data visualization logic.

🔍 Before vs After: The Architecture Shift

❌ Before: Hardcoded Dashboard

Dashboard
 ├── RevenueChart
 ├── ActiveUsersChart
 ├── ErrorRateWidget
 ├── LatencyChart
 └── Many one-off components

Problems:

dashboards tightly coupled to UI code
adding widgets required new components
layout logic lived inside the page
small changes required deployments
component trees kept growing

✅ After: Configuration-Driven Dashboard

Dashboard
   │
   ▼
Dashboard Config
   │
   ▼
Grid Layout Engine
   │
   ▼
Widget Renderer
   │
   ▼
Widget Registry
   │
   ├── LineChartWidget
   ├── StatWidget
   ├── TableWidget
   └── BarChartWidget

Widgets are no longer hardcoded --- they are rendered dynamically from
configuration.

📦 Dashboard Configuration Example

{
  "widgets": [
    {
      "id": "error_rate",
      "type": "line-chart",
      "title": "API Error Rate",
      "description": "Error percentage over time",
      "query": "errors_over_time",
      "layout": { "x": 0, "y": 0, "w": 6, "h": 4 }
    },
    {
      "id": "success_rate",
      "type": "stat",
      "title": "Success Rate",
      "valueFormat": "percentage",
      "layout": { "x": 6, "y": 0, "w": 3, "h": 2 }
    }
  ]
}

This configuration becomes the single source of truth for the
dashboard.

📐 Adding a Layout System

Rendering widgets is only half the challenge. Dashboards also require
flexible layout management.

To solve this, we integrated React Grid Layout, which provides a
responsive drag‑and‑drop grid system.

Instead of hardcoding layout in UI code, widget positioning is also
defined in configuration.

📐 Grid Layout Configuration

{
  "layout": {
    "x": 0,
    "y": 0,
    "w": 6,
    "h": 4
  }
}

Layout properties:

Property Meaning

x horizontal grid position
y vertical grid position
w widget width in grid units
h widget height in grid units

Separating widget configuration from layout configuration keeps
the system clean and extensible.

🧩 Rendering the Grid

import GridLayout from "react-grid-layout"

function Dashboard({ widgets }) {
  const layout = widgets.map(widget => ({
    i: widget.id,
    ...widget.layout
  }))

  return (
    <GridLayout layout={layout} cols={12} rowHeight={80} width={1200}>
      {widgets.map(widget => (
        <div key={widget.id}>
          <WidgetRenderer config={widget} />
        </div>
      ))}
    </GridLayout>
  )
}

This enables:

configuration-driven layouts
flexible widget positioning
consistent dashboard structure

🔒 Adding Type Safety with TypeScript

When dashboards are driven by configuration, type safety becomes
essential.

Widget Type Definitions

Centralizing widget types avoids registry/config mismatches.

export const WidgetTypes = {
  LINE_CHART: "line-chart",
  STAT: "stat",
  TABLE: "table"
} as const

export type WidgetType =
  typeof WidgetTypes[keyof typeof WidgetTypes]

Base Widget Configuration

Every widget shares a common structure.

type BaseWidgetConfig = {
  id: string
  title: string
  description?: string
  type: WidgetType
  layout: GridLayout
}

Stable IDs allow:

drag‑and‑drop persistence
layout tracking
widget analytics
configuration updates

Widget‑Specific Configurations

Each widget extends the base configuration.

type LineChartWidgetConfig = BaseWidgetConfig & {
  type: "line-chart"
  query: string
  timeRange: "1h" | "24h" | "7d"
}

type StatWidgetConfig = BaseWidgetConfig & {
  type: "stat"
  valueFormat?: "percentage" | "number"
  color?: "green" | "red"
}

Union Type for All Widgets

type WidgetConfig =
  | LineChartWidgetConfig
  | StatWidgetConfig

This ensures:

invalid configurations fail at compile time
editors provide autocomplete
widgets remain type-safe as the system grows

🚀 Final Thoughts

Dashboards often start as simple collections of charts but eventually
evolve into complex UI systems.

By combining:

JSON-driven widget configuration
composable React components
a typed widget registry
a grid layout system
stable widget identities

we created a dashboard architecture that scales without turning into a
collection of one-off components.

Widgets are no longer hardcoded UI elements --- they are structured
configuration interpreted by a flexible UI layer.

Huge credits to @145_swatantra_mishra_b100 for rolling out a major chunk of this idea to production.

[Boost]

abhilashlr — Fri, 30 Jan 2026 06:12:02 +0000

Migrating to Next.js 16 & React 19: A Platform Upgrade That Paid Off

abhilashlr ・ Jan 30

#webdev #nextjs #react #ai

Migrating to Next.js 16 & React 19: A Platform Upgrade That Paid Off

abhilashlr — Fri, 30 Jan 2026 04:59:08 +0000

Framework migrations are often framed as maintenance work — necessary, but unexciting.

Our recent migration to Next.js 16 and React 19 turned out to be something more: a platform upgrade that measurably improved performance, security, stability, and developer velocity — while simplifying how we build and reason about our application.

This post shares why we upgraded, what changed technically, and what it now enables — both for engineers working on the product and for the users relying on it every day.

If you are looking for how we phased the upgrade, give this post a read.

🎯 Why We Chose to Upgrade

We were on a stable setup, but over time we started seeing familiar signals:

Security advisories accumulating across the React and Next.js ecosystem
Performance and rendering improvements landing upstream that we couldn’t leverage
Increasing friction adopting modern tooling
Legacy patterns sticking around longer than they should

At a certain point, not upgrading becomes riskier than upgrading.

Rather than treating this as a routine version bump, we approached it as a strategic platform investment — one that would reduce friction for the next 12–24 months.

⚛️ React 19: Fewer Workarounds, Better Defaults

React 19 doesn’t introduce flashy new APIs for everyday development — and that’s a feature, not a limitation.

What stood out during the migration:

More predictable concurrent rendering behavior
Cleaner async handling without excessive defensive code
Reduced reliance on workaround-heavy patterns around effects and state
Better alignment with server-centric application architectures

In practice, this meant:

Fewer rendering edge cases
Cleaner component logic
Easier reasoning about data flow under load

React felt less like something we had to handle carefully and more like something we could trust by default.

🧩 Next.js 16: Stability, Performance, and Security by Default

Next.js 16 reinforced several principles that matter in real-world production systems.

🔄 Improved Rendering & Data Fetching Semantics

Clearer boundaries between server and client components
More predictable caching and revalidation behavior
Fewer hydration mismatches and rendering inconsistencies

⚡ Faster Development Loops

Noticeably quicker dev server startup
Faster rebuilds during local development
Less time waiting, more time iterating

🔐 Security Improvements

A significant class of known vulnerabilities was addressed simply by upgrading — without:

Custom middleware
Manual patching
Forked dependencies

Security became a baseline capability, not an afterthought.

🧠 Turbopack: From Promising to Production-Ready

One of the most impactful improvements during this migration was Turbopack.

Earlier versions felt experimental. With Next.js 16, Turbopack has clearly crossed into mature and production-ready territory.

What we observed:

Significantly faster cold starts in development
Near-instant incremental rebuilds
Stable behavior across a large, real-world codebase
Smooth compatibility with modern Next.js features

This had a direct effect on day-to-day productivity:

Faster feedback loops
Cheaper context switching
A lighter, more responsive debugging experience

Turbopack didn’t just improve performance — it changed the development experience, and those gains compound over time.

📊 Benchmarks: What Changed in Practice

We intentionally avoided synthetic benchmarks and focused on real workflows and production behavior.

Below are the results we observed after migrating to Next.js 16, React 19, and Turbopack.

🛠️ Development Experience

Metric	Before	After	Improvement
Dev server cold start	~45–60s	~8–12s	~6× faster
Incremental rebuild (component change)	2–4s	<500ms	Near-instant
Route change during dev	Noticeable reload	Instant	Qualitative win
CPU usage during dev	High & spiky	Lower & stable	More predictable

Impact:

Engineers spend less time waiting and more time iterating. Over the course of a day, this compounds into a meaningful productivity gain.

🧪 Build & CI Performance

Metric	Before	After
Production build time	Baseline	~20–30% faster
CI flakiness related to builds	Occasional	Near-zero
Bundle warnings & edge cases	Frequent	Significantly reduced

Cleaner builds also made CI logs easier to reason about — an underrated but important improvement.

🌍 Runtime & User-Facing Performance

User-visible gains were incremental rather than dramatic, but consistent and measurable:

Faster initial page loads, especially on server-rendered routes
Smoother client-side navigation
Reduced hydration-related warnings and mismatches
Improved responsiveness under concurrent usage

Rather than chasing headline numbers, the real win was predictability and consistency at scale.

🧯 Stability & Reliability

Post-migration, we observed:

A noticeable drop in rendering-related bugs
Fewer production-only edge cases
Higher confidence shipping UI-heavy changes

React 19 and Next.js 16 handled concurrency and async behavior more predictably, reducing the need for defensive coding patterns.

🛠️ What This Enabled for Engineers

This upgrade unlocked leverage across the engineering workflow.

⚡ Faster Feedback Loops

Faster builds and rebuilds changed how often engineers experiment — and how quickly ideas turn into shipped features.

🧠 Simpler Mental Models

The migration allowed us to:

Remove legacy abstractions
Delete workaround code
Standardize rendering and data-access patterns

Less code, fewer special cases, and more confidence.

🔒 Stronger Security Posture

By aligning with the current ecosystem, we reduced long-term security maintenance and avoided custom defensive layers.

🧭 Lessons We’d Share with Other Teams

If you’re considering a similar migration:

Treat it as a platform investment, not routine maintenance
Break the work into phases — but commit to finishing
Use the opportunity to simplify, not just upgrade
Don’t carry forward legacy patterns unless they still earn their keep

The goal isn’t to be “on the latest version.”

The goal is to reduce friction for the next 12–24 months.

🏁 Closing Thoughts

This migration reset our baseline.

With Next.js 16, React 19, and Turbopack, we’re now building on a platform that:

Is faster in everyday workflows
Is more stable under real-world conditions
Is more secure by default
Reduces long-term maintenance overhead

The benchmarks confirmed what we felt intuitively:

this wasn’t just a successful upgrade — it was a meaningful platform improvement.

If you’ve been delaying a migration like this, we’d strongly recommend taking another look.

🚀 Migrating a Large-Scale Monorepo from Next.js 14 to 16: A Real-World Journey

abhilashlr — Fri, 09 Jan 2026 08:55:23 +0000

🧭 TL;DR

We migrated a large production Next.js monorepo (240+ route files, 3k+ i18n strings) from Next.js 14 → 16 by preparing the codebase first, upgrading dependencies incrementally, and relying heavily on Next.js codemods + AI-assisted refactoring.

The biggest breaking change was async route params, but with a phased approach and automation, we completed the migration in ~2 weeks with minimal production risk.

Upgrading a large enterprise application with a monorepo structure from Next.js 14 to Next.js 16 isn't just about bumping version numbers. It's a carefully orchestrated process that requires understanding breaking changes, preparing your codebase, and migrating incrementally. This post shares our experience migrating a production enterprise application with 240+ files changed and lessons learned along the way.

📊 Project Context

Our setup:

Main Application: Next.js 14.2.35 → 16.1.1
Monorepo: Shared component libraries and utilities (design system, data layer, icons)
Scale: 3,196+ internationalized strings, 240+ route files
Tech Stack: React 18 → React 19, TypeScript 5.8, Styled Components, TanStack Query

🗺️ The Migration Strategy

Phase 1: Preparation (the foundation)

Before touching Next.js itself, we prepared our codebase to be compatible with the new conventions. Think of this as cleaning your house before moving furniture - it makes everything else easier.

Step 1: Update dependencies first

We updated related packages incrementally to avoid dependency conflicts. Why? Because trying to update everything at once is like trying to solve multiple puzzles simultaneously - it's much harder to identify what broke when something goes wrong.

# Bump Next.js 14 to latest patch version
yarn add next@14.2.35

# Update React Query v4 → v5
yarn add @tanstack/react-query@^5.90.12

# Update react-intl for React 19 compatibility
yarn add react-intl@8.0.6

# Update react-select with proper types
yarn add react-select@^5.8.3

Why this matters: Updating dependencies incrementally helps isolate issues. We found that React Query v5 had breaking changes that needed fixes before tackling Next.js. Imagine debugging a broken build when you've changed 10 things at once versus just 1 - that's the difference.

Step 2: Migrate to named React imports

Next.js 16 with React 19 recommends named imports over default imports. What does this mean? Instead of importing React as a whole, we import only the specific pieces we need. We migrated 240+ files to this new pattern:

// Before
import React from 'react';
import { useState } from 'react';

// After
import { useState } from 'react';

We also updated all test utilities and wrapper components:

// Test utilities - Before
import React from 'react';

// After
import { ReactElement, ReactNode } from 'react';

Pro tip: Don't do this manually! We used AI coding assistants to automate this transformation across 240+ files. Think of AI as your tireless intern who never gets bored of repetitive tasks and makes fewer mistakes than humans doing copy-paste work. This saved us hours of tedious work and reduced the chance of human error.

Phase 2: Update monorepo packages

If you have a monorepo (a single repository containing multiple related packages), you need to update shared packages first.

Before migrating the main app, we updated our shared component library packages to support both React 18 and React 19.

// Shared packages - peer dependencies
{
  "peerDependencies": {
    "react": "^18.2.0 || ^19.0.0",
    "react-dom": "^18.2.0 || ^19.0.0"
  }
}

This flexible version range (^18.2.0 || ^19.0.0) means "accept React 18.2.0 or higher, OR React 19.0.0 or higher". This allowed us to:

Test packages independently with React 19
Keep the main app on React 18 until ready
Avoid breaking other projects using the monorepo

Why this matters: It's like having a power adapter that works with both 110V and 220V - you can plug it in anywhere without breaking things.

Phase 3: TypeScript configuration updates

Next.js 16 requires a specific TypeScript setting. We updated tsconfig.json (the TypeScript configuration file):

{
  "compilerOptions": {
    "jsx": "react-jsx", // Changed from "preserve"
    "lib": ["dom", "dom.iterable", "esnext"]
  }
}

The jsx: "react-jsx" setting enables the new JSX transform. Translation: you no longer need to write import React from 'react' at the top of every file. The build system handles it automatically.

Phase 4: Route parameters type migration

This was the biggest change. Next.js 16 made routes type-aware of their parameters - meaning TypeScript now knows exactly which parameters exist for each route, making your code safer and catching errors at compile time instead of runtime.

What are route parameters? They're the dynamic parts in URLs like /products/[id] where [id] could be any product ID.

The challenge: Type-safe route parameters

Previously in Next.js 14, route parameters weren't type-safe at the framework level. We could manually define types, but Next.js didn't enforce them:

// Before - Next.js 14
type Params = {
  id: number;
  categoryId: number;
  view: ViewType; // enum
};

export default function Page({ params }: { params: Params }) {
  const { id, categoryId, view } = params;
  // ...
}

The solution: String parameters with runtime casting

Next.js 16 says "everything from the URL is a string" (because URLs are just text!). So now we convert them to the types we need inside our code:

// After - Next.js 16
type Params = {
  id: string;
  categoryId: string;
  view: string;
};

export default async function Page(props: { params: Promise<Params> }) {
  const params = await props.params;
  const id = Number(params.id);
  const categoryId = Number(params.categoryId);
  const view = params.view as ViewType;
  // ...
}

Key changes explained:

All params are now strings (text) - because that's what URLs actually are
Page props contain Promise<Params> - you must await them (like waiting for a package to arrive before opening it)
Convert numeric IDs with Number() - turning the text "123" into the actual number 123
Cast enum values with as ViewType - telling TypeScript "trust me, this string is one of the valid options"

This affected 120+ route files (yes, that many!). The Next.js codemod handled most of this transformation automatically, creating this consistent pattern across all our routes:

// Layout pattern (created by codemod)
type Params = { id: string };

export default async function Layout(props: {
  params: Promise<Params>;
  children: React.ReactNode;
}) {
  const { id } = await props.params;
  const numericId = Number(id);

  return <LayoutComponent id={numericId}>{children}</LayoutComponent>;
}

// Page pattern (created by codemod)
export default async function Page(props: { params: Promise<Params> }) {
  const params = await props.params;
  // Use params...
}

After the codemod ran, we used AI assistants to handle the parts it couldn't automate - like converting string IDs to numbers and casting enum types.

Phase 5: The main migration

With all the preparation work done (think of it as laying the groundwork), we finally performed the actual Next.js upgrade. This is like changing the engine of a car - you want to make sure everything else is ready before you do it:

# Update Next.js and React
yarn add next@16.1.1 react@18.3.1 react-dom@18.3.1

# Update Next.js tooling
yarn add -D @next/bundle-analyzer@16.1.1 eslint-config-next@16.1.1

# Update React types
yarn add -D @types/react@19.2.7 @types/react-dom@19.2.3

Handling breaking changes

Breaking changes means features that no longer work the way they used to.

1. Removed Next.js config options

Some configuration options no longer exist in Next.js 16:

// next.config.js - Removed
module.exports = {
  // These were removed in Next.js 16
  // distDir: '.next',
  // target: 'serverless',
};

2. Image configuration changes

// next.config.js
module.exports = {
  images: {
    domains: ['...'], // Still works but remotePatterns is the new preferred way
    unoptimized: true,
  },
};

3. Middleware updates

Middleware is code that runs before your pages load. NextJS Codemod should automatically migrate your existing middleware.ts to proxy.ts.

Phase 6: Testing and validation

After the migration, we systematically tested everything.

Type checking: yarn lint
Build: yarn build
Tests: yarn test
Runtime testing: Manual testing of critical paths

We caught and fixed issues like:

// Issue: Async server components not awaited
export default async function Page(props) {
  const params = props.params; // ❌ Missing await

  // Fixed
  const params = await props.params; // ✅
}

🤖 What about codemods?

What are codemods? They're automated tools that rewrite your code following specific patterns. Think of them as find-and-replace on steroids - they understand code structure, not just text.

Next.js provides official codemods for many migrations, and we absolutely used them first! Codemods automated a significant portion of our migration work - like having a robot do the boring repetitive parts.

Codemods we used successfully

# Migrate metadata and generateMetadata exports
npx @next/codemod@latest metadata-to-viewport-export .

# Update Link components
npx @next/codemod@latest new-link .

# Convert async request APIs
npx @next/codemod@latest async-request-api .

These codemods handled:

Converting metadata exports to the new format
Transforming basic async patterns on page/layout files

AI assistants for everything else

After running codemods (which handled the straightforward, pattern-based changes), we used AI coding assistants to handle all the complex stuff that requires understanding context:

Route parameter type conversions - Converting numeric IDs and enums to strings across 120+ route files
Monorepo coordination - Updating shared types across packages with proper context
Named React imports - Transforming 240+ files to use named imports
Context-aware refactoring - Understanding component relationships and dependencies

The AI assistant understood our codebase context and applied patterns consistently, catching edge cases that simple find-and-replace would have missed.

Our recommendation

Use codemods + AI assistants for maximum efficiency!

Run all applicable Next.js codemods first - they'll handle standard Next.js patterns (80-85% of changes)
Review and commit the codemod changes
Use AI coding assistants for everything else - they understand context and can handle complex transformations
Final manual review of critical business logic

This approach completed our migration in 2 weeks instead of what would have taken months manually. The combination of automated codemods and intelligent AI assistance meant we could focus our time on testing and validation rather than mechanical code changes.

The AI-human-CI/CD loop

Our migration followed a continuous improvement cycle that combined AI automation with human oversight:

1. AI makes changes (codemods + Claude Code + AntiGravity)
   ↓
2. Run tests locally (`yarn test`, `yarn lint`)
   ↓
3. Commit and push to GitHub
   ↓
4. GitHub Actions runs CI/CD pipeline
   - Type checking
   - Linting
   - Unit tests
   - Build verification
   ↓
5. Automated code review (CodeRabbit AI)
   - Identifies potential issues
   - Suggests improvements
   - Flags edge cases
   ↓
6. Human code review
   - Verify business logic
   - Check critical paths
   - Approve or request changes
   ↓
7. Fix issues → Repeat from step 1

Key insight: This loop ran dozens of times throughout our phased migration. AI handled the mechanical transformations (80-90% of changes), while humans focused on validating correctness, catching edge cases, and ensuring business logic integrity. Automated tools (CI/CD + CodeRabbit) acted as safety nets, catching issues before they reached production.

The cycle typically took 30-60 minutes per iteration, allowing us to make rapid progress while maintaining code quality.

✅ Migration checklist

Use this checklist for your own migration. Print it out and check off items as you go!

Pre-migration

Update to latest Next.js 14.x patch
Update related dependencies (React Query, react-intl, etc.)
Move non-route files out of /pages/api and /app
Migrate to named React imports
Update monorepo packages for React 19 compatibility
Update TypeScript to 5.x

During migration

Update all route parameters to string types (remember: everything from URLs is text!)
Update Next.js to 16.x
Convert page components to async and await params (add the await keyword)
Update React to 18.3.x (or 19.x if you're feeling brave)
Update @types/react and @types/react-dom (the TypeScript definitions)
Remove deprecated Next.js config options

Post-migration (the victory lap!)

Run type checking (tsc --noEmit)
Run tests
Test build locally
Test development server
Manual testing of critical user paths
Deploy to staging environment
Monitor for runtime errors

⚡ Performance impact

After migration, we measured the actual impact on our application. Here's what we found:

Build time: Extraordinary results! (~50-60% faster with Next.js 16 turbopack improvements). Build time is how long it takes to compile your code for production.

Before

After

Bundle size: Slightly smaller (-3% due to better tree-shaking). Bundle size is the total size of JavaScript your users download - smaller is better!
Development: Faster with Turbopack (we were already using this in Next.js 14).

⚠️ Common pitfalls and solutions

These are the mistakes we made so you don't have to! Learn from our pain.

1. Forgetting to await params

// ❌ Wrong
export default async function Page(props: { params: Promise<Params> }) {
  const { id } = props.params; // Missing await!
}

// ✅ Correct
export default async function Page(props: { params: Promise<Params> }) {
  const { id } = await props.params;
}

2. Type mismatches in nested components

Remember: route params come in as strings, but your components might expect numbers. Always convert!

// Route param is string, but component expects number
const numericId = Number(params.id); // Convert first!

3. Build errors with dynamic routes

generateMetadata is a special function that generates page titles and meta tags. It also needs to await params:

export async function generateMetadata(props: { params: Promise<Params> }) {
  const params = await props.params;
  return { title: `Item ${params.id}` };
}

💡 Key takeaways

The most important lessons we learned:

Prepare incrementally: Don't upgrade everything at once - you do it one thing at a time. Update dependencies (and test), fix code patterns (and test), then upgrade Next.js.
Test continuously: Run type checking and tests after each major change. Catching bugs early is way easier than debugging a mountain of changes.
Understand the changes: Read the Next.js 15 and Next.js 16 release notes thoroughly. I know it's tempting to skip documentation, but trust us - 30 minutes of reading saves hours of debugging.
Async params are non-negotiable: This is the biggest breaking change but thanks to Codemods from Next.js, we were able to automate most of the work.
Monorepo coordination: If you have shared packages (a monorepo), update them first with flexible peer dependencies.
Consider React 19: Next.js 16 works with React 18.3+ but is optimized for React 19. Decide if you want to upgrade React at the same time or separately.

📚 Resources

🎯 Conclusion

Migrating a large-scale application from Next.js 14 to 16 is a significant undertaking, but with proper preparation and incremental changes, it's manageable. Our migration touched 240+ files and took about 2 weeks of focused work, including testing and validation.

The key is to:

Break the migration into phases
Prepare your codebase first
Update dependencies incrementally
Test thoroughly at each step
Document patterns for consistency

We're now running Next.js 16 in production with improved performance and access to the latest React features. The investment in careful migration paid off with a stable, future-proof codebase.

Have you migrated to Next.js 16? What challenges did you face? Share your experience in the comments!

Special thanks to the Next.js team for excellent documentation and the community for sharing their migration experiences.

[Boost]

abhilashlr — Sun, 30 Nov 2025 05:29:07 +0000

abhilashlr

Nov 29 '25

🔥 A Complete, In-Depth Guide to Trusted Types in React and Modern Web Apps

#webdev #security #javascript #react

Comments

5 min read

🔥 A Complete, In-Depth Guide to Trusted Types in React and Modern Web Apps

abhilashlr — Sat, 29 Nov 2025 13:46:45 +0000

Trusted Types in React: A Complete Engineering Guide to Preventing XSS Without Breaking Your App

Trusted Types is one of the most powerful — yet misunderstood — additions to modern browser security. It addresses a problem every frontend engineer encounters eventually: how do we safely render untrusted HTML without opening the door to XSS?

If you’ve ever used:

dangerouslySetInnerHTML
HTML sanitizers
Script injection cleanup
Rich text editors
User-generated content
Markdown → HTML pipelines
Server-rendered CMS content

you’ve already danced around this problem.

This article is a deep-dive into how Trusted Types work, why they matter, and how to integrate them with React, Shadow DOM, and real-world production codebases — without rewriting your entire app.

1. Why Trusted Types Exist

The real problem: "string-to-DOM" APIs are unsafe

APIs like:

element.innerHTML = userInput;
iframe.srcdoc = "...";
script.text = "...";

allow arbitrary strings to be interpreted as DOM or script. If any of that string is user-controlled → you have XSS.

For years, sites relied on sanitizers like DOMPurify. These help, but they can be bypassed if:

The sanitizer is outdated
Someone forgets to sanitize
A dev uses a different code path
A new dangerous API is introduced
Sanitization only happens sometimes

Modern apps use dozens of 3rd-party libraries, each of which might use string → DOM APIs internally.

Trusted Types fixes this structurally.

2. What Trusted Types Actually Do

Trusted Types enforce that any DOM API that expects HTML accepts only a special object, not a string.

Example:

element.innerHTML = "<img src=x onerror=alert(1)>"
// ❌ CSP violation → browser blocks it

But:

const html = myPolicy.createHTML("<b>Hello</b>");
element.innerHTML = html;
// ✅ allowed

The browser now enforces:

Only approved code can turn strings into HTML
That conversion happens through one policy
Every unsafe sink is protected by the browser

This is way more robust than “remembering to sanitize everything”.

3. How React Renders HTML (important!)

React normally sets the HTML for you, not with innerHTML, but through:

<div dangerouslySetInnerHTML={{ __html: html }} />

Internally, React intentionally validates HTML and works through its DOM diffing layers.

But this API still hits an XSS sink.

When Trusted Types are enabled, the browser prevents React from passing plain strings unless they come from a TrustedHTML object.

Thus:

dangerouslySetInnerHTML={{ __html: "<p>hello</p>" }}
// ❌ blocked by Trusted Types

But:

dangerouslySetInnerHTML={{ __html: policy.createHTML("<p>hello</p>") }}
// ✅ safe

4. Setting Up Trusted Types in React

Step 1 — Define a policy

// global script before React mounts
const ttPolicy = window.trustedTypes?.createPolicy("default", {
  createHTML: (string) => DOMPurify.sanitize(string),
});

Important:

Trusted Types do not sanitize.
They only ensure you don’t forget to sanitize.

That’s why you plug in a sanitizer (DOMPurify is the industry standard).

Step 2 — Use the policy where HTML is passed to React

<div
  dangerouslySetInnerHTML={{
    __html: ttPolicy.createHTML(userHTML),
  }}
/>

Note:
ttPolicy.createHTML() returns a TrustedHTML object, not a string.

React doesn’t care — it’ll pass it straight to the DOM.

5. Why createHTML() Is Not a String

This is the most confusing part for developers.

Trusted Types are opaque, branded objects with no .toString().

This is by design:

You should not be able to convert them casually
They should not flow back into string contexts
They must be clearly treated as final sanitized safe DOM fragments

This prevents:

const safe = ttPolicy.createHTML("<p>Hi</p>");
someAPI(safe + "<script>");

This would convert it back to string — which is unsafe.

Trusted Types eliminate this entire class of bugs.

6. Enforcing Trusted Types with CSP

To actually enforce Trusted Types, you set a CSP header:

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types default;

You can also add multiple policies:

trusted-types default dompurify sanitize bleed;

Now every call like:

innerHTML = "<div>"

...is blocked by the browser.

7. Full Example: Rendering User HTML Safely With Trusted Types

Setup the policy

const sanitizePolicy = trustedTypes.createPolicy("sanitize", {
  createHTML: (input) => DOMPurify.sanitize(input),
});

React component

function SafeHtml({ html }) {
  return (
    <div
      dangerouslySetInnerHTML={{
        __html: sanitizePolicy.createHTML(html),
      }}
    />
  );
}

Usage

<SafeHtml html={userComment} />

8. Trusted Types in Shadow DOM (Web Components)

Shadow DOM has separate DOM trees, but Trusted Types work the same.

Example inside a custom element:

class SecureWidget extends HTMLElement {
  set content(html) {
    this.shadowRoot.innerHTML =
      sanitizePolicy.createHTML(html);
  }
}

If you forget:

this.shadowRoot.innerHTML = htmlString;
// ❌ CSP violation

Trusted Types enforce safety inside shadow roots too.

9. Where Developers Usually Get It Wrong (Important)

❌ Mistake 1 — Using Trusted Types without sanitizers

Trusted Types stop accidental sinks, but they do not magically clean HTML.

❌ Mistake 2 — Creating multiple policies

Use one policy per pipeline.

Multiple policies = inconsistent security.

❌ Mistake 3 — Using it only in React components

Any of these are sinks too:

element.insertAdjacentHTML
script.srcdoc
iframe.srcdoc
range.createContextualFragment()

Your policy should cover every path HTML enters the DOM.

10. Advanced Architecture: A Full HTML Safety Pipeline

A robust real-world pipeline looks like this:

1. Input comes from server/client
               ↓
2. Clean with a sanitizer (DOMPurify)
               ↓
3. Convert via Trusted Types policy
               ↓
4. Render via React/shadow DOM

This ensures:

no bypass paths
no forgotten sanitization
browser-level enforcement

11. Real-World Use Cases

1. Rich text editors

Quill, TinyMCE, TipTap — all output HTML.

Trusted Types ensure no editor misconfiguration breaks your app.

2. CMS-rendered content

Blog platforms, Notion embeds, marketing pages.

3. User-generated comments

Forums, reviews, chat apps.

4. Markdown rendering

Markdown → HTML is extremely risky if not sanitized.

12. Final Check: Is Your App Safe Without Trusted Types?

If you use any of these:

dangerouslySetInnerHTML
<iframe srcdoc="...">
HTML sanitization
Web Components with string HTML
3rd-party libraries injecting HTML
UI frameworks like Angular/Old React
Markdown-to-HTML conversion

→ Your app should use Trusted Types.

Modern security requirements (e.g. enterprise customers, finance, healthcare, gov) increasingly require it.

13. Rolling Out Trusted Types Safely: Report Violations Before Enforcing

A common mistake teams make is enabling:

Content-Security-Policy: require-trusted-types-for 'script';

...immediately and breaking half the app.

In reality, the best practice is a two-phase rollout:

Phase 1 — Report‐Only Mode (No Breaking, Just Visibility)

Before you enforce Trusted Types, configure your CSP with:

Content-Security-Policy-Report-Only:
  require-trusted-types-for 'script';
  report-uri https://YOUR-ERROR-MONITORING-ENDPOINT;

OR for Sentry:

Content-Security-Policy-Report-Only:
  require-trusted-types-for 'script';
  report-uri https://sentry.io/api/<project>/security/?sentry_key=<key>;

This allows browsers to send violation events without blocking the app.

You'll start receiving reports any time a library or component incorrectly uses:

innerHTML
insertAdjacentHTML
script.srcdoc
iframe.srcdoc
Range.createContextualFragment()
React components with raw strings

This gives you a map of all unsafe sinks in your app — something nearly impossible to discover manually.

Phase 2 — Send Violations to Your Error Monitoring Tool

You can also catch violations directly in JavaScript and forward them to Sentry, LogRocket, Datadog, or any internal error system.

window.addEventListener("securitypolicyviolation", (e) => {
  // Example: report to Sentry
  Sentry.captureMessage("Trusted Types Violation", {
    level: "warning",
    extra: {
      directive: e.violatedDirective,
      blockedURI: e.blockedURI,
      lineNumber: e.lineNumber,
      columnNumber: e.columnNumber,
      sourceFile: e.sourceFile,
    },
  });
});

Now every Trusted Types violation becomes visible in error dashboards long before users notice breakage.

Phase 3 — Enforce Trusted Types Once Violations Are Near Zero

Only after fixing the violations should you switch from:

Content-Security-Policy-Report-Only: ...

to the enforcing version:

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types default sanitize;

This two-phase strategy is widely used in Enterprise apps, consumer apps with large legacy codebases

It ensures that rolling out Trusted Types is safe, predictable, and does not break production.

Conclusion

Trusted Types are the single most important browser security feature most frontend devs still underestimate. They provide structural protection from XSS regardless of:

who writes the code
which library you use
how complex your UI is

Adding them to a React or Shadow DOM app is not just simple — it’s the kind of engineering discipline that pays off for years.

⚡ Supercharging GitHub Actions CI: From Slow to Lightning Fast with Turbo Caching

abhilashlr — Mon, 03 Nov 2025 12:14:34 +0000

How we optimized our monorepo CI pipeline and reduced build times by 70% using smart caching strategies

🐌 The Problem: Slow CI is a Developer Productivity Killer

Picture this: You're working on a critical feature for your React monorepo. You push your changes, create a pull request, and then... you wait. And wait. Your GitHub Actions CI takes 8-10 minutes to run lint and build checks, grinding your development flow to a halt.

This was exactly our situation with our @atomicworkhq/atomic-ui monorepo - a TypeScript project built with:

6 packages: icons, obsidian (design system), data models, forms, assist, and public apps
Turbo: For coordinated builds and caching
Yarn workspaces: For dependency management
GitHub Actions: For CI/CD

Our original CI was taking way too long, and developers were getting frustrated. Time for an optimization sprint! 🚀

🔍 Analyzing the Original Setup

Here's what our original sanity.yml workflow looked like:

# ❌ BEFORE: Inefficient caching and resource usage
jobs:
  sanity:
    name: Build and Lint
    runs-on: ubuntu-latest
    strategy:
      matrix:
        task: [lint, build]

    steps:
      - name: Check out code
        uses: actions/checkout@v4

      # Basic turbo cache - not optimized
      - name: Cache turbo build setup
        uses: actions/cache@v4
        with:
          path: .turbo
          key: ${{ runner.os }}-turbo-${{ hashFiles('yarn.lock') }}

      # Basic yarn cache
      - name: Fetch yarn cache if available
        uses: actions/cache@v4
        with:
          path: |
            ~/.cache/yarn
            node_modules
          key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}

      # Always install dependencies (even with cache hits)
      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Run task
        run: yarn ${{ matrix.task }}

Issues with the Original Approach

Inefficient dependency installation: Always ran yarn install, even with cache hits
Poor cache keys: Generic cache keys didn't differentiate between tasks or branches
Memory constraints: No memory optimization for Node.js processes
Limited Turbo cache: Only cached .turbo directory, missing ~/.turbo
No cache persistence: Didn't save updated cache for future runs

🛠️ The Optimization Journey

Step 1: Smart Dependency Caching

First, we implemented conditional dependency installation:

# ✅ AFTER: Smart dependency caching
- name: Restore Yarn cache
  uses: actions/cache@v4
  id: cache
  with:
    path: |
      ~/.cache/yarn
      **/node_modules
    key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
    restore-keys: |
      ${{ runner.os }}-yarn-main-

- name: Install dependencies
  if: steps.cache.outputs.cache-hit != 'true'
  run: NODE_OPTIONS="--max_old_space_size=8192" yarn install --frozen-lockfile

Key improvements:

✅ Skip installation when cache hits (saves 2-3 minutes!)
✅ Increased Node.js memory limit to prevent OOM errors
✅ Better cache paths including ~/.cache/yarn

Step 2: Advanced Turbo Caching Strategy

Next, we revolutionized our Turbo caching:

# ✅ AFTER: Advanced Turbo caching with task-specific keys
- name: Restore Turbo cache
  uses: actions/cache@v4
  with:
    path: |
      ~/.turbo
      .turbo
    key: ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}
    restore-keys: |
      ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}
      ${{ runner.os }}-turbo-${{ matrix.task }}-main
      ${{ runner.os }}-turbo-${{ matrix.task }}-

- name: Run task
  run: yarn ${{ matrix.task }}

Improvements:

✅ Task-specific caching: matrix.task in cache keys separates lint vs build artifacts
✅ Branch-aware caching: Uses actual branch names for better cache hits
✅ Comprehensive cache paths: Both ~/.turbo and .turbo directories
✅ Smart fallback hierarchy: Falls back through task → branch → main → generic

Step 3: Memory Optimization in package.json

We also optimized our npm scripts:

{
  "scripts": {
    "build": "NODE_OPTIONS=\"--max_old_space_size=8192\" turbo run build",
    "lint": "NODE_OPTIONS=\"--max_old_space_size=8192\" turbo run check-types"
  }
}

This prevents memory-related build failures in large monorepos.

🎯 The Complete Optimized Workflow

Here's our final, lightning-fast workflow:

name: CI

on:
  pull_request:
    branches: [main]
    types: [opened, synchronize]

jobs:
  sanity:
    permissions:
      contents: read
      actions: write
      pull-requests: read
      packages: read
    name: ${{ matrix.task }}
    runs-on: ubuntu-latest
    strategy:
      matrix:
        task: [lint, build]

    steps:
      - name: Check out code
        uses: actions/checkout@v4
        with:
          fetch-depth: 2

      - name: Setup Node.js environment
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'yarn'

      # Smart Yarn caching
      - name: Restore Yarn cache
        uses: actions/cache@v4
        id: cache
        with:
          path: |
            ~/.cache/yarn
            **/node_modules
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-main-

      - name: Install dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: NODE_OPTIONS="--max_old_space_size=8192" yarn install --frozen-lockfile

      # Advanced Turbo caching
      - name: Restore Turbo cache
        uses: actions/cache@v4
        with:
          path: |
            ~/.turbo
            .turbo
          key: ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}
          restore-keys: |
            ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}
            ${{ runner.os }}-turbo-${{ matrix.task }}-main
            ${{ runner.os }}-turbo-${{ matrix.task }}-

      - name: Run task
        run: yarn ${{ matrix.task }}

📊 Performance Results: The Numbers Don't Lie

Metric	Before	After	Improvement
Cold run time	8-10 minutes	6-7 minutes	25% faster
Warm run time	6-8 minutes	2-3 minutes	70% faster
Cache hit rate	~30%	~85%	183% improvement
Dependency install time	2-3 minutes	10-20 seconds	90% faster
Developer satisfaction	😤	😍	Priceless

🧠 Key Learnings and Best Practices

1. Task-Specific Cache Keys Are Game Changers

# ❌ Generic key - poor cache utilization
key: ${{ runner.os }}-turbo-${{ hashFiles('yarn.lock') }}

# ✅ Task-specific key - much better cache hits
key: ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}

2. Conditional Dependency Installation Saves Massive Time

# Always check if cache was hit before installing
- name: Install dependencies
  if: steps.cache.outputs.cache-hit != 'true'
  run: yarn install --frozen-lockfile

3. Memory Optimization Prevents Random Failures

{
  "build": "NODE_OPTIONS=\"--max_old_space_size=8192\" turbo run build"
}

4. Comprehensive Cache Paths Matter

path: |
  ~/.turbo      # User-level cache
  .turbo        # Project-level cache
  ~/.cache/yarn # Yarn's cache
  **/node_modules # All node_modules

5. Smart Cache Hierarchy Provides Best Fallbacks

restore-keys: |
  ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref }}  # Exact match
  ${{ runner.os }}-turbo-${{ matrix.task }}-main                    # Same task, main branch
  ${{ runner.os }}-turbo-${{ matrix.task }}-                        # Same task, any branch

🚀 Beyond Basic Optimization: Advanced Techniques

Parallel vs Sequential Jobs

We experimented with both approaches:

# Option A: Parallel execution (current)
strategy:
  matrix:
    task: [lint, build]

# Option B: Sequential execution
jobs:
  lint:
    # ... lint job
  build:
    needs: lint # Wait for lint to pass
    # ... build job

Verdict: Parallel wins for speed, but sequential is better for cost optimization and fail-fast scenarios.

Branch-Aware Caching Strategy

# Use actual branch name for PR caching
key: ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}

This ensures each feature branch maintains its own cache while falling back to main branch cache when needed.

🏆 Impact on Developer Experience

The results speak for themselves:

⚡ 70% faster warm builds - Developers get feedback in 2-3 minutes instead of 8-10
💰 Reduced CI costs - Fewer compute minutes = lower GitHub Actions bill
🔄 Faster iteration cycles - Quick feedback loop encourages more frequent commits
😊 Happier developers - No more coffee breaks waiting for CI

🔧 Implementation Guide for Your Project

Want to implement these optimizations in your monorepo? Here's a step-by-step guide:

1. Audit Your Current Workflow

Check your current CI run times
Identify which steps take the longest
Look for redundant operations

2. Implement Smart Caching

# Add these patterns to your workflow
git checkout -b optimize-ci
# Update your .github/workflows/*.yml files
# Test with a small change

3. Monitor and Iterate

Watch your GitHub Actions dashboard
Track cache hit rates
Measure before/after performance

4. Consider Your Monorepo Structure

Single repo with multiple packages? ✅ This approach works great
Independent repos? Consider different cache strategies
Hybrid setup? Mix and match techniques

🤔 Common Pitfalls and How to Avoid Them

1. Over-Caching

# ❌ Don't cache everything
path: |
  ~/.cache
  node_modules
  dist
  .next
  .turbo
  # ... this gets messy

# ✅ Be selective and specific
path: |
  ~/.turbo
  .turbo

2. Cache Key Collisions

# ❌ Too generic - causes conflicts
key: build-cache

# ✅ Include all relevant context
key: ${{ runner.os }}-turbo-${{ matrix.task }}-${{ github.head_ref || github.ref_name }}

3. Forgetting Memory Limits

Large TypeScript monorepos can easily hit Node.js memory limits. Always set:

NODE_OPTIONS="--max_old_space_size=8192"

🔮 Future Optimizations

We're not stopping here! Next up:

Docker layer caching for even faster container builds
Distributed task execution using GitHub's matrix strategy more creatively
Intelligent test splitting to parallelize test suites
Build artifact sharing between workflows

📚 Resources and Further Reading

💬 What's Your Experience?

Have you optimized your CI pipeline recently? What techniques worked best for your team? Drop a comment below and share your optimization wins!

Building fast, reliable CI/CD pipelines is an art and a science. The key is measuring, experimenting, and iterating. Happy coding! 🚀

🏷️ Tags

GitHubActions #CI #Monorepo #Turbo #Performance #DevOps #TypeScript #React #Caching

Global state management in React apps

abhilashlr — Wed, 17 Sep 2025 05:18:29 +0000

Choosing the Right Way to Manage Global State in React Apps

When building modern React applications, one of the most common questions teams face is:

How do we manage state that needs to be accessed by deeply nested components?

It's tempting to reach for React's Context API or start prop-drilling, but as apps grow, these approaches often lead to performance bottlenecks and complex code paths.

In one of our recent projects, we had this exact situation:

React Query was already in place for server state (API-driven data).
Zustand was used for certain client-side needs (local storage, undo/redo).
External libraries brought in their own Context providers.

Now we needed a way to add a global, app-wide local state — accessible from any level of the component tree.

First Principles: Different Types of State

Before deciding how to manage state, it's important to separate server state from client state:

Server state: Data that comes from APIs (users, posts, settings). Best handled by React Query, which gives us caching, background updates, and invalidation out of the box.

Client state: Data that lives only in the app (UI toggles, local preferences, temporary form state). This is where tools like Zustand shine.

Why Not Context for Everything?

React Context has its place — things like theming, localization, and authentication are great fits. But for frequently changing state, Context introduces two problems:

Performance – any update can re-render the entire tree of consumers.
Scalability – as state grows, multiple contexts quickly become hard to maintain.

Why Zustand Works Better Here

Zustand is lightweight, scalable, and avoids the pitfalls of Context. Each component can subscribe only to the part of the store it cares about, so re-renders are isolated.

Here's a simple example:

// store/globalStore.ts
import { create } from "zustand";

type GlobalState = {
  theme: "light" | "dark";
  setTheme: (t: "light" | "dark") => void;

  isSidebarOpen: boolean;
  toggleSidebar: () => void;
};

export const useGlobalStore = create<GlobalState>((set) => ({
  theme: "light",
  setTheme: (t) => set({ theme: t }),

  isSidebarOpen: false,
  toggleSidebar: () => set((s) => ({ isSidebarOpen: !s.isSidebarOpen })),
}));

Usage anywhere in the app:

import { useGlobalStore } from "@/store/globalStore";

function SidebarToggle() {
  const isOpen = useGlobalStore((s) => s.isSidebarOpen);
  const toggle = useGlobalStore((s) => s.toggleSidebar);

  return (
    <button onClick={toggle}>
      {isOpen ? "Close Sidebar" : "Open Sidebar"}
    </button>
  );
}

No prop drilling. No unnecessary re-renders. Just clean, predictable state.

Best Practices and Closing thoughts

As React apps scale, state management decisions compound. The best approach is not to introduce new tools every time a new need arises, but to leverage existing patterns wisely:

Use React Query for server state – don't reinvent async state management.
Use Zustand for client/global state – scalable, performant, and easy to adopt.
Keep Context minimal – only for true cross-cutting concerns like theme or i18n.
Split Zustand stores into slices – avoid a monolithic "god store" by modularizing concerns (UI slice, preferences slice, etc.).

This combination keeps the app consistent, performant, and easy for engineers to maintain.

✨ Curious to hear from other engineers — how do you manage global state in your React apps?

Ember performance tweaks

abhilashlr — Mon, 27 Apr 2020 07:26:25 +0000

I wrote down my experience on performance tweaks that went well for the Ember apps I worked with. Some of them are simple notes that I wrote down while I was tweaking the build pipelines. I share those tips and tricks that could make your Ember apps faster, accessible and awesome!

Before I talk about how to solve for Ember app's performance tips, I presume you have a good understanding of what Ember is, and you have a basic knowledge of its ecosystem, build pipelines, etc.

Key areas to optimise Ember apps:

Improving build timelines & optimising build size
Optimising asset cache
Building and optimising Ember apps for SEO
Improving the accessibility of Ember apps.
Making Ember apps installable.

As I continue to write my blog posts, I will update this post with all the relevant links.

Refactoring Ember templates - Quick tip!

abhilashlr — Mon, 20 Apr 2020 14:01:11 +0000

Originally posted at: https://abhilashlr.in/ember-refactor-templates

Some of us might have written complex if-else logic in our Ember templates (a.k.a HTMLBars templates). There could be scenarios where certain lines of code look almost similar, but we keep them as-is for readability. Perhaps, writing a shorter version of it makes the entire file readable with concise LoC. Let's assume a simple bootstrap-like HTML + text content (using translations):

{{#if isInfo}}
  <i class="icon-info"></i>
  {{t "info.title"}}
{{else if isWarn}}
  <i class="icon-warn"></i>
  {{t "warn.title"}}
...
{{/if}}

Now the problem with this LoC is readability in itself if there were similar HTML all around this page's template file. In such cases, you can opt for a computed property that finds the right key and use it on the template. Something like below:

<i class="icon-{{type}}"></i>{{t (concat type ".title")}}

Amazing, now we have 13 lines shortened to 1 line.
Bonus Tip 1:

Let's say you have no control over the t helper's key and that it would be a specific use case based on your API or 3rd party services.

In such scenarios, one way is to optimise this in your JS code, based on switch conditions and decide which key you would want to use. That would be unit-testable code base. Let's say you would want to do this if-else in the template like the following:

<i class="icon-alert margin-right-20"></i>
{{#if condition1}}
  {{t "something_from_server1"}}
{{else if condition2}}
  {{t "something_from_3rdparty_service"}}
{{else}}
  {{t "generic_message"}}
{{/if}}

If you notice a bit closer, there is a class called margin-right-20 on the icon. Generally, icon + text lines on the UI tend to have a minor space between them. Since our templates use a sequence of if-else conditions, this internally introduces whitespace around the moustache ({}) code that is present. And if you see closer on the UI, the icon + text would end up having a 20px margin on the right and a white space introduced just before the TextNode (generated by the translation helper).

Like I said before, one way to fix this is by generating the key on the javascript side and rendering the same in a single line. Or if you still like to do this on your template, you can use the ~ character by the braces, something like below:

<i class="icon-alert margin-right-20"></i>
{{~#if condition1}}
  {{~t "something_from_server1"}}
{{~else if condition2}}
  {{~t "something_from_3rdparty_service"}}
{{~else}}
  {{~t "generic_message"}}
{{/if}}

And inspecting the rendered HTML in the Browser inspector shows

Here's a good read on the same: Whitespace Control.
Bonus Tip 2:

If the same HTML of icon and text's parent holds a display: flex or display: inline-flex, despite whitespace being present, it would not be visible on the UI output.

Here's a twiddle for you to try.