DEV Community: Mikhail Yarmaliuk

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.