DEV Community: Lomray Software LLC

react-mobx-manager 4.6.0: persisting MobX stores without rewriting all of them

Melissa Ashford — Thu, 05 Nov 2026 21:50:25 +0000

Persistence in react-mobx-manager used to be simple and a bit wasteful. Every persisted store had a MobX reaction on toJS(store), and toJS walks every observable the store can reach, including other stores referenced from its fields. So a loading flag flipping in one store could make another store serialize itself again. Then every save wrote the whole storage value: one JSON blob holding all persisted stores.

Version 4.6.0 (released 30 September, PR #53, promoted to latest in #54) reworks this. Short version: it saves less, and less often.

What the listener watches now

The change listener tracks only the fields that are actually persisted. That is the union of the attributes you route to storages, or all exported fields when you use '*'. Stores referenced from those fields are no longer traversed.

So if a persisted store also has short-lived fields, keep them out of storage. They stop causing persist work:

import { Manager, makeExported } from '@lomray/react-mobx-manager';

export default Manager.persistStore(FeedStore, 'feed', {
  behaviour: 'include',
  attributes: { local: ['items', 'filters'] },
});

// or inside the store constructor
makeExported(this, { isFetching: 'excluded' });

Saves are batched

Stores that change within options.persistDelay (100 ms by default) are serialized once, and each storage gets one write. A store whose persisted state did not change is not written again.

const manager = new Manager({
  storage,
  options: { persistDelay: 300 },
});

This is a behaviour change. A save can now land up to persistDelay after the change. Need the old timing? Set persistDelay: 0. On the server the manager always saves immediately.

The queue is written right away in four cases. The page is hidden (pagehide, or visibilitychange to hidden). A store with queued changes is destroyed. You call manager.destroy(). Or you call manager.flushPersist() yourself. React Native has no page events, so flush when the app goes to background:

import { AppState } from 'react-native';

AppState.addEventListener('change', (state) => {
  if (state !== 'active') {
    void manager.flushPersist();
  }
});

flushPersist() resolves when the writes finish, to false if something failed or persistence is disabled. In tests that read storage right after a change, await it first.

One key per store: KeyValueStorage

LocalStorage, SessionStorage, CookieStorage and AsyncStorage keep all persisted stores in one value, and their data format did not change in 4.6.0. If you have many or large stores, KeyValueStorage saves each store under its own key and writes only the stores that changed. Values also stay small. The docs point out why that matters on Android: a single AsyncStorage row of around 2 MB may fail to load.

import AsyncStorage from '@react-native-async-storage/async-storage';
import { Manager } from '@lomray/react-mobx-manager';
import MobxAsyncStorage from '@lomray/react-mobx-manager/storages/async-storage';
import CombinedStorage from '@lomray/react-mobx-manager/storages/combined-storage';
import KeyValueStorage from '@lomray/react-mobx-manager/storages/key-value-storage';

const manager = new Manager({
  storage: new CombinedStorage({
    local: new KeyValueStorage({
      storage: AsyncStorage,
      // stores saved by the previous setup are moved on the first start
      migrateFrom: new MobxAsyncStorage({ storage: AsyncStorage }),
    }),
  }),
});

Any backend with getItem, setItem and removeItem works, sync or async. MMKV, for example:

import { createMMKV } from 'react-native-mmkv';

const mmkv = createMMKV();

const storage = new KeyValueStorage({
  storage: {
    getItem: (key) => mmkv.getString(key),
    setItem: (key, value) => mmkv.set(key, value),
    removeItem: (key) => mmkv.remove(key),
  },
});

Stores land under stores:<storeId> next to a stores-keys index. prefix changes the prefix.

Migration is conservative

migrateFrom is read only when the new storage has no index yet, which means the first start. The old data stays where it was by default, so rolling back to an older app version still finds it. Pass shouldRemoveMigrated: true to remove it right after migration. If the migrated stores cannot be saved, the app still starts with the old data, and every store is saved again on the next change.

IndexedDB for the web

IndexedDBStorage saves each store as its own record. Writes are asynchronous, and the quota is much larger than the roughly 5 MB localStorage gives you.

import CombinedStorage from '@lomray/react-mobx-manager/storages/combined-storage';
import IndexedDBStorage from '@lomray/react-mobx-manager/storages/indexed-db-storage';
import LocalStorage from '@lomray/react-mobx-manager/storages/local-storage';

const storage = new CombinedStorage({
  local: new IndexedDBStorage({
    // moved on the first start and used when IndexedDB is not available
    migrateFrom: new LocalStorage(),
  }),
});

State comes back asynchronously in manager.init(). Wait for it before rendering persisted stores, for example with shouldInit on StoreManagerProvider. If IndexedDB cannot be opened, the storage reads and writes migrateFrom instead.

Smaller things

Custom storages can implement an optional saveChanges({ value, changes, toJSON }) to write only what changed. Plain set still works.
CookieStorage warns once in the console when the value goes over 4 KB.
A store that cannot be serialized (a BigInt, say) no longer breaks saving for the others.

Numbers, with a caveat

PR #53 includes a synthetic benchmark: 24 persisted stores, about 750 KB of state, stores referencing other stores, frequent loading-flag changes, an AsyncStorage-like backend, run in Node in client mode.

	before	after, single value	after, KeyValueStorage
CPU spent on persistence	~3.8 s	~0.1-0.2 s	~0.2 s
storage writes	92	11	71 (small)
bytes written	47 MB	7.6 MB	1.4 MB

The final persisted state matched the previous version. It is one synthetic setup, and your app will show different numbers.

A request for /.env shouldn't render your React app

Melissa Ashford — Tue, 22 Sep 2026 01:17:49 +0000

A request for /.env doesn't need a React tree. In the latest release, vite-ssr-boost can reject it before your request hook runs.

The document guard is on by default. The SSR concurrency limit isn't.

Your hook might not run

The default document methods are GET, HEAD and POST. Other methods get 405 with an Allow header before onRequest, HTML loading or route loaders. If your hook handles CORS preflights, include OPTIONS in requestGuard.methods alongside the methods you still need. That array replaces the defaults.

Allowing a method doesn't bypass the other checks. For allowed methods, oversized targets get 414 and malformed paths get 400. With the default rules, GET requests for /.env or /random.php get a plain 404 without rendering. An unmatched /missing.xml does too; a matched resource route such as /sitemap.xml can pass.

requestGuard: false disables the new guard and its missing-page handling. This is document-handler behavior, not protection for every request reaching your server.

Choose what a missing page does

For an unmatched document such as /missing, notFound defaults to render: the existing router/render path. spa serves a client shell with 404; detected bots still take the render path under the default bot policy. A custom Response gives you a static 404 without the render pipeline.

A catch-all route counts as a match. To apply a missing-page mode there, return 'notFound' from requestGuard.decide.

cached buffers a router 404 and reuses it while the entry is retained. Concurrent misses for the same key share a render. Hits skip onRequest and the render pipeline, including loaders and admission. Don't depend on those hooks running for every missing page.

The default key is shared across missing paths, including the first rendered URL and hydration data. Cold renders use GET without the original body, with Cookie and Authorization removed before the request hook. The URL, other headers and application state can still affect the result. Keep private state out of shared HTML; choose keys for public variations such as locale. If the page depends on a session, keep ordinary rendering instead.

A configured CSP nonce disables this cache and falls back to ordinary rendering. Failed renders and non-404 results aren't retained. Overloads and server failures keep their error status; a request-hook bypass keeps its own response. The default private, no-store header on 404 documents can be overridden by document header rules. This HTML cache is separate from browser or CDN caching.

Limit renders, not every bit of server work

Admission is opt-in and handler-local, not a cluster-wide cap.

Set a positive safe integer in admission.maxConcurrency, or a valid SSR_MAX_CONCURRENCY. The environment value wins and is read at handler/entry creation. No limit is enabled by default.

A slot is taken after request initialization and the SSR/SPA decision, before route loaders. At capacity the default response is 503 with Retry-After and private, no-store. There is no admission queue. The rejected request's loaders don't run, but onRequest and HTML loading have already happened.

With admission.overload: 'spa', requests that reach a full admission controller get a 200 shell for humans and 503 for detected bots. That isn't the missing-page SPA mode, whose shell uses 404. A custom overload Response is sent as 503.

On normal streamed completion, the slot stays occupied until the final Fetch response stream is consumed, not merely until React produces a shell. This doesn't mean the last byte has reached the browser. Aborts and errors can release it earlier; redirects and bodyless responses have their own release paths. Ordinary SPA shells and cached 404 hits don't occupy a slot.

Before deploying, test a preflight that must reach your hook. Check that missing URLs don't share private data. For admission, keep one response stream open and send another SSR request at capacity.

Configuration reference, guard and 404 tests, admission tests.

We deleted Vite from our production server

Melissa Ashford — Mon, 21 Sep 2026 16:59:28 +0000

vite-ssr-boost is an SSR framework built on Vite. Its production server used to start this way: load Vite, resolve vite.config, build the full CLI command tree, then serve the first request. None of that is needed to serve HTML.

In 8.4.x we cut it out. The numbers below are our own runs on a pinned template, M3 Pro, installed through npm.

What the production start used to do:

load Vite and evaluate vite.config
build the whole Commander command tree just to parse the flags of start
spin up the source analysis services that only dev mode uses

What it does now:

ssr-boost build writes a versioned build/server/ssr-boost.json with the resolved serving settings. Production reads that file and never evaluates the Vite config.
ssr-boost start parses its flags with Node's own parser. Every other command loads on demand, keyboard shortcuts load only when there is a TTY.
An import hook watches the serving path. It rejects vite, rolldown, rollup, commander, diff, parse5, semver, json5 and the babel packages, and it also rejects our own dev-only code: the cli commands, the build, manifest and route parsing services, the plugins. That is the part that keeps it honest. The hook catches accidental imports before they reach production.

What it bought:

cold start 354 ms to 249 ms. A plain Express server with renderToPipeableStream is 171 ms on the same machine.
RSS 142 MiB to 100 MiB. Same plain Express baseline: 69 MiB.

Then the per-request path. React's native Web stream on React 19.2+, the production shell cached instead of rebuilt, boundary scanning only while data frames can still arrive, a plain state script for routes without router data, static dispatch by built prefixes so there is no filesystem lookup per HTML request, the header queued at shell readiness, compression flushed before drain.

One more part, the one I would copy even if you skip everything else. Acceptance measures a plain Express baseline in the same run and fails the build if cold start goes past 2x that baseline. RSS has its own ceiling in the same file. So if a later change drags the start path back toward Vite, CI fails on a number instead of on someone's memory.

We also keep a public benchmark repo that runs five SSR frameworks weekly in CI and stores the raw json for every cell: https://github.com/Lomray-Software/ssr-benchmarks. Read it yourself, our claims here are about our own before and after, not about anyone else's framework.

If you run SSR on Vite, go look at what your production process loads before it answers anything. Count the modules, or run start under --cpu-prof.

We were loading a build tool in production. It cost about 100 ms and 40 MiB per process.

Code: https://github.com/Lomray-Software/vite-ssr-boost
Docs: https://lomray-software.github.io/vite-ssr-boost/
The PRs with the full detail: https://github.com/Lomray-Software/vite-ssr-boost/pull/53, https://github.com/Lomray-Software/vite-ssr-boost/pull/54, https://github.com/Lomray-Software/vite-ssr-boost/pull/55

Creating Mobx Stores Manager: A Fresh Perspective

Mikhail Yarmaliuk — Fri, 04 Aug 2023 10:42:29 +0000

Manage your Mobx stores like a boss — debug like a hacker.

Hello there!👋 I'm Mikhail, the Chief Technology Officer👮‍♀️ at Lomray Software. Today, I'm excited to share our decision in mobx for managing stores.

In a sea🌊 of existing solutions, you might be wondering if there's room for one more. Allow me to assure you — this isn't just another rehash of the same old state tree concept. While established approaches certainly have their merits, I propose an alternative. As the saying goes, "two heads are better than one" and in that spirit, I present to you an innovative perspective that I believe everyone should consider.

A New Take on State Management:
If you're anything like me, you've grown somewhat weary of the conventional state tree🌲 models. Whether it's the state tree of Redux or the Mobx approach, it's hard to escape their omnipresence, even in basic Google searches. Seeking something both novel and familiar, I embarked on a journey🔍 to reimagine the paradigm, particularly after transitioning from Redux to Mobx not long ago.

import { combineReducers } from 'redux';
import AppInfoReducer from '@store/modules/app-info/reducer';
import FormApplicationReducer from '@store/modules/form-application/reducer';
import FormPopupReducer from '@store/modules/form-popup/reducer';
import FormQuizReducer from '@store/modules/form-quiz/reducer';
import FormSubscribeReducer from '@store/modules/form-subscribe/reducer';
import PageMetaReducer from '@store/modules/page-meta/reducer';
import BlogDetailsReducer from '@store/modules/pages/blog-details/reducer';
import BlogInfoReducer from '@store/modules/pages/blog/info/reducer';
import BlogListReducer from '@store/modules/pages/blog/list/reducer';
import BlogTagsReducer from '@store/modules/pages/blog/tags/reducer';
import Think3DetailsReducer from '@store/modules/pages/think3-details/reducer';
import Think3CitiesReducer from '@store/modules/pages/think3/cities/reducer';
import Think3InfoReducer from '@store/modules/pages/think3/info/reducer';
import Think3ListReducer from '@store/modules/pages/think3/list/reducer';
import Think3TagsReducer from '@store/modules/pages/think3/tags/reducer';
import Think1DetailsReducer from '@store/modules/pages/think1-details/reducer';
import Think1InfoReducer from '@store/modules/pages/think1/info/reducer';
import Think1ListReducer from '@store/modules/pages/think1/list/reducer';
import Think1TagsReducer from '@store/modules/pages/think1/tags/reducer';
import ContactPageReducer from '@store/modules/pages/contact/reducer';
import HomeGraphReducer from '@store/modules/pages/home/graph/reducer';
import HomePageReducer from '@store/modules/pages/home/info/reducer';
import Think2DetailsReducer from '@store/modules/pages/think2-details/reducer';
import Think2InfoReducer from '@store/modules/pages/think2/info/reducer';
import Think2ListReducer from '@store/modules/pages/think2/list/reducer';
import Think2TagsReducer from '@store/modules/pages/think2/tags/reducer';
import OurTeamPageReducer from '@store/modules/pages/our-team/reducer';
import PrivacyPolicyReducer from '@store/modules/pages/privacy-policy/reducer';
import SearchReducer from '@store/modules/pages/search/reducer';
import FormCvReducer from '@store/modules/post-cv/reducer';

const reducers = {
  pages: combineReducers({
    home: combineReducers({
      info: HomePageReducer,
      graph: HomeGraphReducer,
    }),
    think1: combineReducers({
      info: Think1InfoReducer,
      list: Think1ListReducer,
      tags: Think1TagsReducer,
    }),
    think1Details: Think1DetailsReducer,
    think2: combineReducers({
      info: Think2InfoReducer,
      list: Think2ListReducer,
      tags: Think2TagsReducer,
    }),
    think2Details: Think2DetailsReducer,
    ourTeam: OurTeamPageReducer,
    think3: combineReducers({
      info: Think3InfoReducer,
      tags: Think3TagsReducer,
      list: Think3ListReducer,
      cities: Think3CitiesReducer,
    }),
    think3Details: Think3DetailsReducer,
    blog: combineReducers({
      info: BlogInfoReducer,
      list: BlogListReducer,
      tags: BlogTagsReducer,
    }),
    blogDetails: BlogDetailsReducer,
    contact: ContactPageReducer,
    search: SearchReducer,
    privacyPolicy: PrivacyPolicyReducer,
  }),
  appInfo: AppInfoReducer,
  formSubscribe: FormSubscribeReducer,
  formCv: FormCvReducer,
  pageMeta: PageMetaReducer,
  formPopup: FormPopupReducer,
  formApplication: FormApplicationReducer,
  formQuiz: FormQuizReducer,
};

export default reducers;

It’s small application😰 (some names replaced)

A Challenge of Duplication:
Let's be candid—have you ever sought a solution that facilitates the concurrent use of components connected to a store? Have you faced the task of running a connected component multiple times across various pages📑 in your React app or screens in React Native? As you survey your app, you might find the state tree🌴🌴🌴 growing unwieldy, leading to complex code (as demonstrated above). While alternate libraries could potentially address this, I wanted a different solution—one that aligned with the class-based approach that Mobx employs.

Try to run same page twice, which connected to one state tree node

Embracing Mobx's Strengths:
I've always been drawn✍️ to Mobx's class-based methodology. The advantages offered by classes are difficult to ignore, especially when it comes to business logic and state management. However, a curious cycle emerges—while attempting to streamline one library's functionality, we often find ourselves introducing another, and then another. This chain of dependencies complicates development, requiring mastery of multiple tools and their nuances. Furthermore, onboarding new developers to this "monster"🐙 can be a daunting task.

Try to write app with new state management library

The Quest for Centralization:
Although Mobx's documentation showcases rudimentary store usage examples, it becomes apparent that a centralized approach is missing. Interactions between stores and certain debugging tools may feel reminiscent of Redux—an acquaintance many of us share. This lack of seamless integration and default code splitting options is evident upon deeper🪔 exploration.

/**
 * Example redux
 */

/**
 * Action types
 */
enum EXAMPLE_ACTION_TYPE {
  EXAMPLE_USER_GET = 'EXAMPLE_USER_GET',
  EXAMPLE_USER_GET_SUCCESS = 'EXAMPLE_USER_GET_SUCCESS',
  EXAMPLE_USER_GET_ERROR = 'EXAMPLE_USER_GET_ERROR',
}

/**
 * Action creators
 */

const getUser = (): IAction<EXAMPLE_ACTION_TYPE> => ({
  type: EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET,
  payload: {},
});

const getUserSuccess = (user: Record<string, any>): IAction<EXAMPLE_ACTION_TYPE> => ({
  type: EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET_SUCCESS,
  payload: { user },
});

const getUserError = (message: string): IAction<EXAMPLE_ACTION_TYPE> => ({
  type: EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET_ERROR,
  payload: { message },
});

/**
 * Reducer
 */

const initState = {
  fetching: false,
  error: null,
  result: null,
};

const reducer = (
  state = initState,
  { type, payload }: IAction<EXAMPLE_ACTION_TYPE> = {},
): IAppInfoState => {
  switch (type) {
    case EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET:
      return { ...initState, fetching: true };

    case EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET_ERROR:
      return { ...initState, error: payload.message };

    case EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET_SUCCESS:
      return { ...initState, result: payload.user };

    default:
      return { ...state };
  }
};

/**
 * Saga
 */

function* getUserSaga(): SagaIterator {
  try {
    // axios request
    const { data } = yield call(() => axios.get('/users/123'));

    yield put(getUserSuccess(data));
  } catch (e) {
    yield put(getUserError(e.message));
  }
}

export default [
  takeLatest(EXAMPLE_ACTION_TYPE.EXAMPLE_USER_GET, getUserSaga),
];

/**
 * Example Mobx state tree
 */

import { values } from "mobx"
import { types, getParent, flow } from "mobx-state-tree"

export const User = types.model("User", {
  id: types.identifier,
  name: types.string,
})

export const UserStore = types
  .model("UserStore", {
    fetching: false,
    error: null,
    user: types.reference(User),
  })
  .actions((self) => {
    function setIsFetching(fetching) {
      self.fetching = fetching
    }

    function setUser(user) {
      self.user = user;
    }

    function setError(error) {
      self.error = error;
    }

    function getUser() {
      try {
        setIsFetching(true);
        const { data } = await axios.get("/users/123")
        setUser(data);
        setIsFetching(false)
      } catch (err) {
        setError("Failed to load user")
      }
    })

    return {
      getUser,
      setUser
    }
  })

import { makeObservable, observable, action } from "mobx"

interface IUser {
  id: number;
  name: string;
}

class UserStore {
  user: IUser | null = null;
  fetching = false;
  error: string | null = null;

  constructor() {
    makeObservable(this, {
      user: observable,
      fetching: observable,
      error: observable,
      setIsFetching: action.bound,
      setError: action.bound,
      setUser: action.bound,
    })
  }

  setIsFetching(fetching: boolean) {
    this.fetching = fetching;
  }

  setError(error: string | null) {
    this.error = error;
  }

  setUser(user) {
    this.user = user;
  }

  getUser = async () => {
    this.setIsFetching(true);

    try {
      const {data} = await axios.get("/users/123")
      this.setUser(data);
    } catch (e) {
      this.setError("Failed to load user")
    } finally {
      this.setIsFetching(false);
    }
  }
}

Introducing React Mobx Manager:
Enter the solution: React Mobx Manager. Picture this as a singleton—an information repository housing details about all instantiated stores, their contexts, and the linked component names. With this approach, you sidestep the need to build and configure an entire state tree from scratch. Instead, you create dedicated stores for each component, only as necessary. Furthermore, accessing a pre-existing store from another store becomes a breeze🌬💧. The need for complex code splitting is diminished through clever store techniques that mimic React context functionality. You can even concurrently mount identical pages or screens while retaining state integrity. For those interested, a Reactotron plugin is available, and work on browser🌐 extensions is underway.

Visualizing the Concept:
To illustrate this concept visually, consider the following diagram:

Mobx Store Manager idea

First we need to create a manager and wrap our application in a context (entrypoint src/index.tsx)

import React from 'react';
import ReactDOM from 'react-dom/client';
import { Manager, StoreManagerProvider } from '@lomray/react-mobx-manager';
import User from './user';

const storeManager = new Manager();

const root = ReactDOM.createRoot(document.getElementById('root') as HTMLElement);

root.render(
  <React.StrictMode>
    <StoreManagerProvider storeManager={storeManager} shouldInit fallback={<div>Loading…</div>}>
      <User />
    </StoreManagerProvider>
  </React.StrictMode>,
);

Then we create a store and connect it to the component:

import type { FC } from 'react';
import { makeObservable, observable } from 'mobx';
import type { IConstructorParams, StoresType } from '@lomray/react-mobx-manager';
import { withStores } from '@lomray/react-mobx-manager';

class UserStore {
  /**
   * Required only if we don't configure our bundler to keep classnames and function names
   * Default: current class name
   */
  static id = 'user';

  /**
   * You can also enable 'singleton' behavior for global application stores
   * Default: false
   */
  static isSingleton = true;

  /**
   * Our state
   */
  public name = 'Matthew'

  /**
   * @constructor
   */
  constructor(params: IConstructorParams) {
    makeObservable(this, {
     name: observable,
   });
  }
}

/**
 * Define stores for component
 */
const stores = {
 userStore: UserStore
};

/**
 * Support typescript
 */
type TProps = StoresType <typeof stores>;

/**
 * User component
 */
const User: FC<TProps> = ({ userStore: { name } }) => {
 return (
   <div>{name}</div>
 )
}

/**
 * Connect stores to component
 */
export default withStores(User, stores);

Done!✅

I’ll just show how it all looks in the reactotron debugger:

If this has piqued your interest, waste no time in diving🤿 into the mechanics. Allow me to provide you with a practical example.

Conclusion:
React Mobx Manager isn't gunning for any awards. Rather, it's an alternative perspective and a personal choice. Whether you embrace it or not, the decision ultimately rests with you. I genuinely appreciate your time spent on this article and am eagerly open to any ideas or suggestions you may have on this matter.

Vite SSR BOOST: Forging Our Unique Journey in the Realm of React SSR⚡

Mikhail Yarmaliuk — Thu, 03 Aug 2023 10:55:42 +0000

Develop ⚡charged⚡ server side applications with Vite SSR Boost

Hello there!👋 I'm Mikhail, the Chief Technology Officer👮‍♀️ at Lomray Software. Today, I'm excited to share a brief overview of our journey in creating a custom framework tailored for developing React applications with robust Server-Side Rendering (SSR) support. Additionally, I'll be unveiling the outcomes of our endeavors.

As the adage goes, monumental achievements often originate from humble beginnings. In our scenario, we initially managed a handful of React applications lacking SSR capabilities. Gradually, the need to transition these applications toward server-side rendering emerged. Given that the standard navigation within regular React applications (SPA, CRA) is managed by the react-router library, we embarked on a quest to find a solution enabling seamless deployment of existing apps with minimal adjustments for SSR. Unfortunately, the landscape for SSR solutions within the React ecosystem, especially in conjunction with react-router🛣, was somewhat limited. Next.js, for instance, didn't align with our objectives due to its routing system and specific features. Eventually, we encountered a framework named after.js, which granted us the means to bring our vision to life. However, over time, we encountered the obstacle of React and related libraries undergoing significant updates while after.js remained stagnant. Despite amassing a commendable number of GitHub stars⭐, its development was unfortunately halted.

Confronted with a dearth of viable alternatives and armed with insights from current trends, we opted to forge our own framework, leveraging cutting-edge technologies to address prevailing challenges. It's important to acknowledge our appreciation for Next.js and the Vite SSR Plugin, both of which offer an exceptional SSR development experience. Regrettably, their routing systems fell short of our expectations. Our chief aim was to facilitate a seamless transition from a standard React application to SSR (and vice versa), requiring minimal modifications. The ultimate goal was for the resultant application to be deployable in both SSR and SPA modes.

Allow me to introduce the Vite SSR BOOST🔋. Originally conceptualized as a plugin, it organically matured into a comprehensive library.

🔑Key highlights of Vite SSR BOOST:

Flexibility for developing applications as SSR or SPA (CRA).
Effortless toggling between SSR and SPA modes at any point.
Streamlined building process with no need for SSR or SPA-specific adjustments.
Seamlessly integrated react-router for streamlined navigation.
Harnessing the full potential of Vite's capabilities.
Native support for rendering to a stream (rendertopipeablestream).
Full compatibility with Suspense.

What is notable is that having minimal knowledge in Node.js and React Router is sufficient. Here’s a brief example of an application page:

import { Suspense} from '@lomray/consistent-suspense';
import type { FCRoute } from '@lomray/vite-ssr-boost/interfaces/fc-route';
import { Link, useLoaderData } from 'react-router-dom';
import UserPlaceholder from './components/placeholder';
import User from './components/user';

interface ILoaderData {
  userIds: string[];
}

/**
 * Just simple page which render short info about 3 users by id's
 */
const Details: FCRoute = () => {
  const { userIds } = useLoaderData() as ILoaderData;

  return (
    <>
      <p>
        Header
      </p>
      <p>
        Load users for id's: {userIds.join(', ')}
      </p>
      <div>
        <Suspense fallback={<UserPlaceholder count={2} />}>
          <>
            <Suspense.NS>
              <User userId="user-1" />
            </Suspense.NS>
            <Suspense.NS>
              <User userId="user-3" />
            </Suspense.NS>
          </>
        </Suspense>
        <Suspense fallback={<UserPlaceholder />}>
          <User userId="user-2" />
        </Suspense>
      </div>
      <p>
        Footer
      </p>
    </>
  );
};

/**
 * Just example (react-router API)
 */
Details.loader = (): ILoaderData => {
  const userIds = ['user-1', 'user-2', 'user-3'];

  return { userIds };
};

export default Details;

Certainly, our journey encountered significant challenges along the way. However, in the spirit of the adage, "what doesn't kill you, makes you stronger." Instead of overwhelming you with a multitude of words, I'm thrilled to present a demo repository showcasing an application where, alongside the framework itself, we've successfully tackled several related development issues.

We're eager to hear your thoughts and welcome any feedback you may have. Your input serves as a tremendous motivator for us. Thank you for your valuable attention.