Forem: Ogasawara Kakeru

ReactJs Performance ~ State Management~

Ogasawara Kakeru — Fri, 17 Apr 2026 20:45:57 +0000

・The choice of state management can have a dramatic effect on React performance, but most comparisons focus on developer experience rather than runtime characteristics.

Having implemented Context, Redux, Zustand and Jotai in production apps, the following factors were found to be important: re-render frequency, serialisation overhead and selector performance. Each solution balances these factors differently.

Tool	My Impression	Trade-off	Good Use Case
Context API	Simple but limited at scale	Re-renders can spread easily	Local or tightly related state
Redux	Structured and predictable	More setup and concepts	Large apps with strong debugging needs
Zustand	Lightweight and practical	Less opinionated structure	Modern apps that value simplicity
Jotai	Flexible and fine-grained	Requires understanding atom-based thinking	Derived and modular state
Recoil	Good for dependent state	Heavier choice for some teams	Complex state relationships
MobX	Powerful and reactive	Different mental model	Observable-style architecture

A pitfall for Context API:
When using the Context API, updating a single value (like mode) will cause all components consuming the context to re-render.

import { createContext, useState } from 'react';

const UIContext = createContext(undefined);

export function UIProvider({ children }) {
  const [theme, setTheme] = useState('dark');
  const [account, setAccount] = useState(null);

  // Even a small change like "theme" will trigger re-render for all consumers
  const state = {
    theme,
    updateTheme: setTheme,
    account,
    updateAccount: setAccount,
  };

  return (
    <UIContext.Provider value={state}>
      {children}
    </UIContext.Provider>
  );
}

Solution: Split contexts according to their update frequency:

// Contexts split by how often they change
const AccountContext = createContext(null);      // Rare updates
const AppearanceContext = createContext(null);   // Medium updates
const AlertContext = createContext(null);        // Frequent updates

// Each component subscribes only to the data it actually needs
function Navbar() {
  const account = useContext(AccountContext); // Re-renders only when account changes

  return <p>Hello, {account?.username}</p>;
}

The Zustand approach offers better performance:

import { create } from 'zustand';

// Components subscribe only to specific slices of state
const useAppStore = create((set) => ({
  account: null,
  colorMode: 'dark',
  messages: [],

  updateAccount: (account) => set({ account }),
  switchMode: (mode) => set({ colorMode: mode }),
  pushMessage: (msg) =>
    set((prev) => ({
      messages: [...prev.messages, msg],
    })),
}));

// This component reacts only to "colorMode"
function ModeSwitcher() {
  const colorMode = useAppStore((s) => s.colorMode);
  const switchMode = useAppStore((s) => s.switchMode);

  return (
    <button onClick={() => switchMode(colorMode === 'dark' ? 'light' : 'dark')}>
      Switch Mode
    </button>
  );
}

ReactJs Performance ~Code Splitting and lazy Loading Storatrgies~

Ogasawara Kakeru — Mon, 13 Apr 2026 23:15:34 +0000

The size of your JavaScript bundle directly impacts your First Contentful Paint (FCP) and Largest Contentful Paint (LCP), which are two critical Core Web Vitals metrics that affect both user experience and SEO rankings.

The problem is that most React apps ship one massive JavaScript bundle containing every component, library and feature. Users on mobile devices download megabytes of code for features they might never use. My rule of thumb is that if a feature isn't visible when the page first loads, it shouldn't

Strategic code splitting approaches:
Route-based splliting

import { lazy, Suspense } from 'react';

//Users download only when they visit
const Home= lazy(() => import('./pages/Home'));
const About= lazy(() => import('./pages/About'));
const Detail= lazy(() => import('./pages/Detaile'));

function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <Routes>
        <Route path="/home" element={<Home/>} />
        <Route path="/about" element={<About/>} />
        <Route path="/detail" element={<Detail/>} />
      </Routes>
    </Suspense>
  );
}

Conponent-based splitting

// Down load hevy component when you need it.
const Video= lazy(() => import('./Video'));

function MediaSection({ showVideo }) {
  return (
    <div>
      {showVideo && (
        <Suspense fallback={<p>Loading...</p>}>
          <Video/>
        </Suspense>
      )}
    </div>
  );
}

Library splitting

// Only load when needed
const PDF = () => import('react-pdf');
const Excel = () => import('xlsx');

async function handleExport(type) {
  if (type === 'pdf') {
    const { PDFDownloadLink } = await PDF();
    // Use PDFDownloadLink
  } else if (type === 'excel') {
    const XLSX = await Excel();
    // Use XLSX
  }
}

✨ Code Splitting: Practical Impact Overview

Here’s a simplified breakdown of how different code splitting strategies affect performance and when to use them:

Strategy	Bundle Size Reduction	Performance Gain (TTI)	Complexity	When It Works Best
Route-based split	~60–80%	~40–60% faster	Easy	Applications with multiple pages
Component split	~30–50%	~20–35% faster	Moderate	Pages with many independent features
Library split	~20–40%	~15–30% faster	Easy	Projects using large third-party libraries
Vendor split	~15–25%	~10–20% faster	Easy	Long-term caching optimization
Dynamic import	~40–70%	~30–50% faster	Moderate	Features loaded on demand
Prefetching	N/A (preloading)	~50–80% faster navigation	Moderate	Predictable user interactions

ReactJs Performance ~React Compiler~

Ogasawara Kakeru — Sun, 12 Apr 2026 22:12:48 +0000

React 19 introduced the React Compiler to optimize components without useMemo or useCallback.

Before

const Component = ({ datas}) => {

  const memoizedDatas= useMemo(() => {
    return datas.map(item => format(item));
  }, [datas]);

  const handleOnClick = useCallback(() => {
    doSomething(memoizedDatas);
  }, [memoizedDatas]);

  return <div onClick={handleOnClick}>{memoizedDatas.map(data => data.item)}</div>;
};

After

const Component = ({ datas}) => {

  const memoizedDatas= datas.map(item => format(item));

  const handleOnClick= () => {
    doSomething(memoizedDatas);
  };

  return <div onClick={handleOnClick}>{memoizedDatas.map(data => data.item)}</div>;
};

ReactJs Performance ~React Rendering Pattern~

Ogasawara Kakeru — Fri, 10 Apr 2026 08:48:56 +0000

・Before dealing with performance optimization, we have to understand React Rendering Pattern, which makes the app slow.

React's rendering issues are composed of three phases as follows:
・Trigger of render: changing of state or props.
・Rendering of components: calling components.
・Committing changes to the DOM.

Most of the issues are involved in the rendering of components, such as unnecessary calling components or too heavy calculations.

React19 introduced the React Compiler that memoizes components and values automatically by applying useMemo and useCallback everywhere it's safe to do so. However, it doesn't solve architectural issues such as overlaying broad context providers or huge component trees.

Unnecessary re-renders

Unnecessary re-renders happen when a component updates even though its props or state haven’t changed, which can introduce delays and make interactions feel sluggish.

Excessive computations

Excessive computations during rendering can block the main thread, causing temporary UI freezes and reducing overall responsiveness.

Rendering large lists

Rendering large lists all at once increases processing time, which can lead to noticeable delays and choppy scrolling.

Context update cascades

When a context value changes, it can trigger re-renders across many components, resulting in slower updates and degraded performance.

Inline function usage

Defining functions inline within components creates new instances on every render, which can add overhead and lead to subtle performance issues.

Deep component trees

Deep component trees increase rendering complexity, which can slow down both initial page load and subsequent updates.

ReactJs Performance Strategy Profiler

Ogasawara Kakeru — Tue, 07 Apr 2026 22:38:26 +0000

You can measure the performance of the app by wrapping the component tree with <Profiler>.

<Profiler id="App" onRender={onRender}>
  <App />
</Profiler>

Props

id: The string that identifies which part of the UI is measured.
onRender: The callback that receives information about what is rendered and how much time is taken.

onRender callback

function onRender(id, phase, actualDuration, baseDuration, startTime, commitTime) {
  // Aggregate or log render timings...
}

params
id: The id property of the <Profiler> corresponding to the tree that was just committed. If you are using multiple profilers, this allows you to identify which tree was committed.

phase: “mount”, ‘update’, or “nested-update”. This indicates whether the tree was mounted for the first time or re-rendered due to changes in props, state, or hooks.

actualDuration: The number of milliseconds the and its child elements spent rendering for the current update. This indicates how effectively the subtree is utilizing memoization (e.g., memo and useMemo). Ideally, this value should decrease significantly after the initial mount as more child elements are rendered only when their props change.

baseDuration: An estimate in milliseconds of the time it would take to re-render the entire subtree without optimizations. It is calculated by summing the time taken for the last render of each component in the tree. This value estimates the worst-case rendering cost of the tree (e.g., during initial mount or when memoization is not used). To verify whether memoization is working, compare this value with actualDuration.

startTime: The timestamp of when React began rendering the current update.

commitTime: The timestamp of when React committed the current update. Since this value is shared across all profilers within a single commit, it can be used for grouping as needed.

Pitfall
Because profiling introduces additional overhead, it is disabled by default in production builds. To perform profiling in a production environment, you must explicitly use a special production build with profiling enabled.

Note
You can use the element to collect measurement results programmatically. If you prefer an interactive profiler, try the Profiler tab in React Developer Tools. It provides similar functionality as a browser extension.

ReactJS ~Clean Code DRY~

Ogasawara Kakeru — Sun, 05 Apr 2026 07:06:26 +0000

Clean code is DRY
DRY is an acronym that stands for Don't Repeat Yourself. If you are doing the same thing in multiple places, consolidate the duplicate code. If you see patterns in your code, that is an indication that it is prime for DRYing. Sometimes this means standing back from the screen until you can't read the text and literally looking for patterns.

// Dirty
const MyComponent = () => (
  <div>
    <OtherComponent type="a" className="colorful" foo={123} bar={456} />
    <OtherComponent type="b" className="colorful" foo={123} bar={456} />    
  </div>
);

// Clean
const MyOtherComponent = ({ type }) => (
  <OtherComponent type={type} className="colorful" foo={123} bar={456} />
);
const MyComponent = () => (
  <div>
    <MyOtherComponent type="a" />
    <MyOtherComponent type="b" />
  </div>
);

ReactJS ~Server Functions~

Ogasawara Kakeru — Sat, 04 Apr 2026 00:21:54 +0000

・The sever functions in React is the asynchronous function in server component that can be called from slient component.

Previously, it used to be called server actions though, it is called server functions that covers more wide range features such as query for database.

Basic features
・"use server" directive: You have to add "use server"; at the top of the file or that of the file to define it as the server function.

・Automatic RPC: When you call it from client component, React create HTTP request(POST), run the server function. and return the result of it.

・Type Safety: If you use TypeScript, it enables us to develop an application safely checking types of the parameters or returns between server and client.

・Serialize Constraints: Numbers, stings and objects must be type of data that is sirializable, because parameters and returns are sent over the network.

Usage

Data Mutation: When mutating the server state by sending form, and create, update and delete data.
Progressive Enhancement: It enables us to send form by calling sserver function throguh <form action={...}> before JavaScript is loaded on the browser.
Concealment of confidential information: You can conceal logics such as manitulation for data base or utilizing APIs that should not be exposed to client.

Usage Environment as of 2026
・React 19: Server functions were introduced as a stable feature in React 19.

・Frameworks: Currently, Next.js’s App Router is the most prominent implementation, but support is also expanding in other frameworks such as TanStack Start, react-server, and React Router (preview).

Implementation Example (Next.js / React 19)
By defining a function with “use server”; and passing it directly to the action attribute of a client-side component's form, you can seamlessly invoke server-side processing.

// actions.ts (server side)
'use server';
export async function submitData(formData: FormData) {
  //do something on server
}

// ClientComponent.tsx (client side)
import { submitData } from './actions';
export function MyForm() {
  return <form action={submitData}>...</form>;
}

ReactJS SOLID Principle　~ DIP (Dependency Inversion Principle)~

Ogasawara Kakeru — Tue, 31 Mar 2026 22:45:37 +0000

・The dependency that imports an extra module should depend on the abstract interface, but not the concrete one.

Because this makes it easy to modify the application, while an application that depends on a concrete interface might collapse immediately.

Here is an example using the swr.

import useSWR from 'swr'

const fetcher = async (url) => {
  const res = await fetch(url)
  return res.json()
}

export const Todo = () => {
  const { data } = useSWR('https://jsonplaceholder.typicode.com/todos', fetcher)

  if (!data) return <p>loading....</p>

  return (
    <ul>
    {data.map((todo) => {
      return (
        <li>
          <span>{todo.id}</span>
          <span>{todo.title}</span>
        </li>
      );
    })}
  </ul>
  )
}

The snippet above has several issues.

・Fetches data within the Todo component.
・The Todo component depends on the concrete interface.

Let's consider if we convert the swr to the react-query that provides superior functionality than swr. Can we do it easily?

Here are several issues.

・Variety of components depends on the swr directly. We are bound to replace it in every component.

・If each component has its own different errors, we have to fix them.

And other issues exist in the application.

Let's deal with the issue by applying the DPI to direct the dependency to the interface.

import useSWR from 'swr'

interface IUseFetch<T> {
  key: string
  fetcher: () => Promise<T>
}

interface IResponse<T> {
  data: T | undefined,
  error: string | undefined
  isValidating: boolean
}

export const useFetch = <T>({ key, fetcher }: IUseFetch<T>): IResponse<T> => {
  const { data, error, isValidating } = useSWR<T, string>(key, fetcher)

  return {
    data,
    error,
    isValidating
  }
}

import { useFetch } from './useFetch'

type ResponseType = {
  id: number
  title: string
}

const fetcher = async (): Promise<ResponseType[]> => {
  const url = 'https://jsonplaceholder.typicode.com/todos'
  const res = await fetch(url)
  return res.json()
}

export const Todo = () => {
  const { data } = useFetch<ResponseType[]>({ key: '/todos', fetcher })

  if (!data) return <p>loading....</p>

  return (
    <ul>
    {data.map((todo) => {
      return (
        <li>
          <span>{todo.id}</span>
          <span>{todo.title}</span>
        </li>
      );
    })}
  </ul>
  )
}

Above codes, we defined useFetch hook to wrap the swr, and call it from the Todo component.

In this case, we have only to modify the useFetch hook if we apply the react-query in the application.

ReactJS SOLID Principle　~ISP (Interface Segregation Principle)~

Ogasawara Kakeru — Sun, 29 Mar 2026 05:49:13 +0000

In React, the interface(props defined as TypeScript) should have only types that are used in the component.

For example:

import React, { VFC } from "react";

type PostType = {
  title: string;
  author: {
    name: string;
    age: number;
  };
  createdAt: Date;
};

export const Post = ({ post }: { post: PostType }) => {
  return (
    <div>
      <PostTitle post={post} />
      <span>author: {post.author.name}</span>
      <PostDate post={post} />
    </div>
  );
};

type Props = {
  post: PostType;
};

export const PostTitle: VFC<Props> = ({ post }) => {
  return <h1>{post.title}</h1>;
};

type DateProps = {
  post: PostType;
};

export const PostDate: VFC<DateProps> = ({ post }) => {
  return <time>{post.createdAt}</time>;
};

The Post component has the Posttitle component and the PostDate component.
One shows title, the other shows post date.

This breaks the ISP.

The Posttitle component depends on the post: PostType property. But this component actually uses the name property. This means that the Posttitle depends on the unnecessary interface.

If the post: PostType is modified, this has an effect on the PostTitle component and PostDate component.

ISP is also related to SRP and OCP; if interfaces are not properly separated, a component may end up having more than one responsibility, leaving it vulnerable to changes during extension.

Therefore, this issue can be resolved by defining only the necessary interfaces, as shown below.

import React, { VFC } from "react";

type PostType = {
  title: string;
  author: {
    name: string;
    age: number;
  };
  createdAt: Date;
};

export const Post = ({ post }: { post: PostType }) => {
  return (
    <div>
      <PostTitle title={post.title} />
      <span>author: {post.author.name}</span>
      <PostDate date={post.createdAt} />
    </div>
  );
};

type Props = {
  title: string;
};

export const PostTitle: VFC<Props> = ({ title }) => {
  return <h1>{title}</h1>;
};

type DateProps = {
  date: Date
};

export const PostDate: VFC<DateProps> = ({ date }) => {
  return <time>{date}</time>;
};

ReactJS SOLID Principle　~LSP (Liskov Substitution Principle)~

Ogasawara Kakeru — Fri, 27 Mar 2026 08:04:06 +0000

・In React, LSP indicates that when you expand the base component or HTML, you should not break base functionality.

Bad code

// You can not use the normal button
const CustomButton = ({ label }: { label: string }) => {
  return <button>{label}</button>;
};

// The onClick is ignored if you pass. And type is an error.
<CustomButton label="preserve" onClick={() => alert('Preserved')} />

Good code
You should extend all attributes of the button and pass it.

import { ComponentPropsWithoutRef } from 'react';

//Define the type to receive all of the attributes
interface ButtonProps extends ComponentPropsWithoutRef<'button'> {
  variant?: 'primary' | 'secondary';
}

const CustomButton = ({ variant, children, ...rest }: ButtonProps) => {
  const style = variant === 'primary' ? { backgroundColor: 'blue' } : {};

  // pass all of the attributes such as onClick or type by `...rest`
  return (
    <button style={style} {...rest}>
      {children}
    </button>
  );
};


<CustomButton variant="primary" onClick={() => console.log('Submit')}>
  Submit
</CustomButton>

In this way, the essence of LSP is to ensure that “whatever the parent (standard element) can do, the child (custom component) can do as well.”

ReactJS SOLID Principle　~OCP (Open Closed Principle)~

Ogasawara Kakeru — Wed, 25 Mar 2026 11:16:47 +0000

The OCP principle states that:
The extent of the component or function should be open, and its modification should be closed.

Bad code

import React, { VFC } from "react";

type Props = {
  title: string;
  type: "default" | "withLinkButton" | "withNormalButton";
  href?: string;
  buttonText?: string;
  onClick?: () => void;
};

export const Title: VFC<Props> = ({
  title,
  type,
  href,
  buttonText,
  onClick,
}) => {
  return (
    <div style={{ display: "flex", justifyContent: "space-between" }}>
      <h1>{title}</h1>
      {type === "withLinkButton" && (
        <button onClick={onClick}>
          <a href={href}>{buttonText}</a>
        </button>
      )}
      {type === "withNormalButton" && (
        <button onClick={onClick}>{buttonText}</button>
      )}
    </div>
  );
};

This component receives props such as title, type, and so forth.
There are three use cases: a non-displaying button; a displaying button to the left of the title, and a normal displaying button.

*Why does this component breach the OCP? *

Let's consider a scenario.
After the product was released, a manager ordered us to create a page with a tooltip that appears next to the title.

Therefore, I modified the page that displays the tooltip, adding the withTooltip type to the props type.

Each time we expand the functionality, we have to modify the component. This means that, when you modify the component, you have to check for any degradation. This slows down the development process.

Although there are a variety of solutions, the Composition Component Pattern is used in this case.

import { VFC, FC } from "react";

type TitleProps = {
  title: string;
};

export const Title: FC<TitleProps> = ({ title, children }) => {
  return (
    <div style={{ display: "flex", justifyContent: "space-between" }}>
      <h1>{title}</h1>
      {children}
    </div>
  );
};

type TitleWithLinkProps = {
  title: string;
  href: string;
  buttonText: string;
};

export const TitleWithLink: VFC<TitleWithLinkProps> = ({
  title,
  href,
  buttonText,
}) => {
  return (
    <Title title={title}>
      <button>
        <a href={href}>{buttonText}</a>
      </button>
    </Title>
  );
};

type TitleWithButtonProps = {
  title: string;
  buttonText: string;
  onClick: () => void;
};

export const TitleWithButtonProps: VFC<TitleWithButtonProps> = ({
  title,
  buttonText,
  onClick,
}) => {
  return (
    <Title title={title}>
      <button onClick={onClick}>{buttonText}</button>
    </Title>
  );
};

I broke the component down into smaller parts so that I could pass the inner component as a child. By doing this, if you need to implement the “additional modification to place a tooltip next to the title” mentioned earlier, for example, you simply need to draw the component that displays the tooltip within the TitleWithTooltip component. This will not affect the TitleWithButton or TitleWithLink components in any way.

ReactJS SOLID Principle　~SRP (Single Responsibility Principle)~

Ogasawara Kakeru — Fri, 20 Mar 2026 08:03:49 +0000

In the context of React, this can be rephrased to mean that there should be only one reason to change a component or function.

Let's start by looking at some bad code to make it easier to understand.

import React, { useEffect, useState } from "react";
import axios from "axios";

type TodoType = {
  id: number;
  userId: number;
  title: string;
  completed: boolean;
};

export const TodoList = () => {
  const [data, setData] = useState<TodoType[]>([]);
  const [isFetching, setIsFetching] = useState(true);

  useEffect(() => {
    axios
      .get<TodoType[]>("https://jsonplaceholder.typicode.com/todos")
      .then((res) => {
        setData(res.data);
      })
      .catch((e) => {
        console.log(e);
      })
      .finally(() => {
        setIsFetching(false);
      });
  }, []);

  if (isFetching) {
    return <p>...loading</p>;
  }

  return (
    <ul>
      {data.map((todo) => {
        return (
          <li>
            <span>{todo.id}</span>
            <span>{todo.title}</span>
          </li>
        );
      })}
    </ul>
  );
};

The TodoList component fetches Todo items and renders the UI based on the fetched data.
You may occasionally come across components like this in projects, but they violate the Single Responsibility Principle (SRP) for the following reasons.

The same component handles two responsibilities: fetching data and rendering the TODO list.

For example, if the endpoint specified in the fetch section changes, you would have to modify the contents of the TodoList component. Similarly, if you want to change the title’s styling, you would also need to modify this component.
Since there are multiple reasons why this component might need to be changed, it’s important to properly separate its responsibilities. Fortunately, in React, you can use custom hooks to separate the fetching logic from the component’s rendering, so we’ll extract the fetching logic into a custom hook.

import React, { useEffect, useState } from "react";
import axios from "axios";

type TodoType = {
  id: number;
  userId: number;
  title: string;
  completed: boolean;
};

export const useFetchTodo = () => {
  const [data, setData] = useState<TodoType[]>([]);
  const [isFetching, setIsFetching] = useState(true);

  useEffect(() => {
    axios
      .get<TodoType[]>("https://jsonplaceholder.typicode.com/todos")
      .then((res) => {
        setData(res.data);
      })
      .catch((e) => {
        console.log(e);
      })
      .finally(() => {
        setIsFetching(false);
      });
  }, []);

  return {
    todo: data,
    isFetching,
  };
};

export const TodoList = () => {
  const { todo, isFetching } = useFetchTodo();

  if (isFetching) {
    return <p>...loading</p>;
  }

  return (
    <ul>
      {todo.map((todo) => {
        return (
          <li>
            <span>{todo.id}</span>
            <span>{todo.title}</span>
          </li>
        );
      })}
    </ul>
  );
};

By doing this, the component no longer needs to know the specifics of the fetching process; it only needs to be aware of the interface. For example, even if you later need to add error handling to the fetch process, you can simply modify useFetchTodo without changing the component itself.