Image Credit & Copyright: Mike Selby
By the end of 2024, all code that could be written out of React should be written out of React.
When I first started learning React, I learned from the documentation how to use useEffect to send requests and manage connections, similar to the example that still exists today.
// https://react.dev/reference/react/useEffect#useeffect
function ChatRoom({ roomId }) {
const [serverUrl, setServerUrl] = useState('https://localhost:1234');
useEffect(() => {
const connection = createConnection(serverUrl, roomId);
connection.connect();
return () => {
connection.disconnect();
};
}, [serverUrl, roomId]);
// ...
}I’ve spent years wrestling with useEffect, attempting to solve various challenges and issues.
I became proficient in various react-xxx tools (react-query saved me a while) and gained a deep understanding of React’s rendering behavior (just kidding, it’s too hard). I evangelized “Thinking in React” to everyone around me until, one day, I realized that coding in React was becoming less and less enjoyable. Perhaps something fundamental was misunderstood from the beginning.
Language shapes the way we think. I had become overly accustomed to the development paradigm of creating UI Components and then writing code where these UI Components drive data fetching and side effects. I realized this wasn’t how I approached coding when I started programming.
Long ago, when I was writing PHP, the page rendering process followed this pattern:
- Parse the HTTP Request
- Execute a series of MySQL queries
- Combine the query results and pass them to the PHP template engine
Does it sound like MVC? While mentioning MVC in 2024 might seem outdated, I found my development life simpler after experimenting with this traditional development approach in React for a while.
Setting React aside, if I were to implement a new View framework from scratch, this is how I would envision it:
// This is imaginary/conceptual code demonstrating the idea
async function Page() {
render(<Skeleton />)
const user = await fetchUser();
const chatRoom = await connectRoom(user.authTicket);
render(<ChatRoom user={user} chatRoom={chatRoom} />)
}
(() => {
try {
Page()
} catch (err) {
render(<ErrorPage />)
}
})()React provides <Suspense /> and <ErrorBoundary /> to implement loading state and error handling. However, this is merely a workaround due to JSX’s limitations with async/await and try/catch. I want to use async/await because it’s much more powerful, for example, to implement flexible loading progress bars like this:
async function Page() {
render(<Skeleton progress="0.1" />)
const user = await fetchUser();
render(<Skeleton progress="0.2" />)
const connection = await connectRoom(user.authTicket);
render(<Skeleton progress="0.3" />)
const chatRoom = await fetchRoomInfo(connection.sessionId);
render(<ChatRoom user={user} chatRoom={chatRoom} />)
}After realizing this, I made a concerted effort to extract the code from React, attempting to refactor the code from this pattern:
export function App({userId}) {
const [user, setUser] = useState();
const [loading, setLoading] = useState();
useEffect(() => {
setLoading(true);
fetch('/api/users/' + userId)
.then((resp) => resp.json())
.then((u) => {
setLoading(false);
setUser(u);
});
}, [userId]);
if (loading) {
return <div>Loading...</div>;
}
return <>{user?.name}</>;
}Refactoring it into this structure:
// atoms.js
export const userId$ = $value(0)
export const init$ = $func(({set}) => {
const userId = // ... parse userId from location search
set(userId$, userId)
})
export const user$ = $computed(get => {
const userId = get(userId$)
return fetch('/api/users/' + userId).then(resp => resp.json())
})
// App.jsx
export function App() {
const user = useLastResolved(user$);
return <>{user?.name}</>;
}
// main.jsx
const store = createStore();
store.set(init$)
const rootElement = document.getElementById('root')!;
const root = createRoot(rootElement);
root.render(
<StoreProvider value={store}>
<App />
</StoreProvider>,
);I developed a lightweight state management library, Rippling, to facilitate this coding approach. Jotai can also achieve the same functionality.
- Initiate the data loading process in the function out of React
- Store the React rendering data through an external state management library
- React only handles rendering the data into HTML
By managing data through an external state library, React returns to being purely a View layer, becoming a replaceable component. The data can also be rendered using the DOM API:
import { createDebugStore, $value, $func, setupDevtoolsInterceptor } from 'rippling';
const interceptor = setupDevtoolsInterceptor(window);
const store = createDebugStore(interceptor);
const count$ = $value(0);
const render$ = $func(
({ get }) => {
const count = get(count$);
document.getElementById('count').textContent = count;
}
);
store.set(render$);
store.sub(count$, render$);
document.getElementById('increment').addEventListener('click', () => {
store.set(count$, (x) => x + 1);
});Moreover, a standalone router implementation can be achieved in under 100 lines of code, independent of React:
import { $computed, $func, $value, Func } from 'rippling';
const reloadPathname$ = $value(0);
const pathname$ = $computed((get) => {
get(reloadPathname$);
return window.location.pathname;
});
export const navigate$ = $func(({ set }, pathname: string, signal?: AbortSignal) => {
window.history.pushState({}, '', pathname);
set(reloadPathname$, (x) => x + 1);
set(loadRoute$, signal);
});
interface Route {
path: string;
setup: Func<void, [AbortSignal]>;
}
const inertnalRouteConfig$ = $value<Route[] | undefined>(undefined);
export const currentRoute$ = $computed((get) => {
const config = get(inertnalRouteConfig$);
if (!config) {
return null;
}
const match = config.find((route) => route.path === get(pathname$));
if (!match) {
return null;
}
return match;
});
const loadRouteController$ = $value<AbortController | undefined>(undefined);
const loadRoute$ = $func(({ get, set }, signal?: AbortSignal) => {
get(loadRouteController$)?.abort();
const currentRoute = get(currentRoute$);
if (!currentRoute) {
throw new Error('No route matches');
}
const controller = new AbortController();
set(loadRouteController$, controller);
set(currentRoute.setup, AbortSignal.any([controller.signal, signal].filter(Boolean) as AbortSignal[]));
});
export const initRoutes$ = $func(({ set }, config: Route[], signal: AbortSignal) => {
set(inertnalRouteConfig$, config);
set(loadRoute$, signal);
window.addEventListener(
'popstate',
() => {
set(reloadPathname$, (x) => x + 1);
set(loadRoute$, signal);
},
{ signal },
);
});Building an SPA with this Router feels like going back a decade:
export const main$ = $func(({ set }, signal: AbortSignal) => {
set(beginAutoRefresh$, signal);
set(
initRoutes$,
[
{
path: '/',
setup: $func(async ({ set }) => {
set(pageNode$, <Skeleton />
const user = await get(user$);
if (!user) {
set(navigate$, '/login')
return;
}
set(pageNode$, <HomePage />);
}),
// ...
},
]
)
})Why is React Router so complex? It has to be very complicated to handle nested routes and state reuse. Once I moved state management outside of React, I found that nested route refresh issues no longer plagued me.
To validate this approach, I developed a personal finance Dashboard. While it’s considerably more straightforward than my previous commercial projects, I believe it’s a solid proof of concept.
I’m also experimenting with this pattern in a more complex project called Motiff and seeing promising results. The entire editor loading section (which has tons of async flow) has been successfully extracted from React, and now I’m working on replacing more useEffect implementations.
Language shapes the way we think. React encourages developers to drive logic orchestration through UI, but I don’t prefer this approach. I won’t miss the days of wrestling with useEffect.
