הגדרת ארכיטקטורת MobX לאפליקציות React Native

אתם בונים אפליקציית React Native ומגלים שניהול state עם Redux צורך עד 40% מהזמן שלכם בכתיבת קוד boilerplate. עם ניסיון של 5+ שנים ב-React Native ו-50+ פרויקטים שהועברו, מצאנו ש-MobX היא הדרך המהירה ביותר ליישם ניהול state ריאקטיבי. Actions, reducers, selectors, normalization — הכל יכול להיות מוחלף ב-store observable תמציתי. MobX הוא מנהל state ריאקטיבי המבוסס על ערכים observable. במקום dispatch, משתמשים במוטציות ישירות; במקום mapStateToProps, משתמשים ב-wrapper של observer. עבור React Native עם mobx-react-lite, אנחנו מקבלים קוד קומפקטי ללא wrappers מיותרים. צרו קשר להערכת פרויקט.

הצוות שלנו מקים ארכיטקטורת MobX מקצה לקצה, ומבטיח תאימות עם TypeScript, ניווט והתראות push. נבחן את הפרויקט שלכם ונציע לוחות זמנים החל מיומיים. קבלו ייעוץ — נראה לכם איך לקצץ קוד ב-60%.

בעיות שאנחנו פותרים

• Boilerplate מוגזם: Redux דורש actionTypes, יוצרי action, reducers, combineReducers עבור כל מודול. MobX עם makeAutoObservable מסמן שדות ומתודות עבורכם אוטומטית.
• עדכונים אסינכרוניים: לאחר await, הקונטקסט של ה-action אובד. אנחנו משתמשים ב-runInAction למוטציות בטוחות — מונעים שינויים מקריים מחוץ ל-action.
• מורכבות אינטגרציה: עם React Native, useEffect ומנויים מרובים גורמים לעיתים קרובות לבעיות. MobX עם observer() עוקב אוטומטית רק אחרי ה-observables שבשימוש, וממזער re-renders.

למה MobX על פני Redux עבור React Native?

import { makeAutoObservable, runInAction } from 'mobx';

class ProfileStore {
    profile: UserProfile | null = null;
    isLoading = false;
    error: string | null = null;

    constructor(private userRepository: UserRepository) {
        makeAutoObservable(this);
    }

    async loadProfile(userId: string) {
        this.isLoading = true;
        this.error = null;
        try {
            const profile = await this.userRepository.getProfile(userId);
            runInAction(() => {
                this.profile = profile;
                this.isLoading = false;
            });
        } catch (e) {
            runInAction(() => {
                this.error = (e as Error).message;
                this.isLoading = false;
            });
        }
    }

    get displayName() {
        return this.profile ? `${this.profile.firstName} ${this.profile.lastName}` : '';
    }
}

import { makeAutoObservable, runInAction } from 'mobx'; class ProfileStore { profile: UserProfile | null = null; isLoading = false; error: string | null = null; constructor(private userRepository: UserRepository) { makeAutoObservable(this); } async loadProfile(userId: string) { this.isLoading = true; this.error = null; try { const profile = await this.userRepository.getProfile(userId); runInAction(() => { this.profile = profile; this.isLoading = false; }); } catch (e) { runInAction(() => { this.error = (e as Error).message; this.isLoading = false; }); } } get displayName() { return this.profile ? `${this.profile.firstName} ${this.profile.lastName}` : ''; } } מסמן שדות כ-makeAutoObservable, מתודות כ-observable, getters כ-action. במצב strict, MobX דורש computed, ולכן action הוא חובה עבור תרחישים אסינכרוניים — זה מונע מוטציות מקריות מחוץ ל-action.

ברכיב:

const ProfileScreen = observer(({ userId }: { userId: string }) => {
  const { profileStore } = useStores();
  useEffect(() => {
    profileStore.loadProfile(userId);
  }, [userId]);
  if (profileStore.isLoading) return <ActivityIndicator />;
  if (profileStore.error) return <ErrorView message={profileStore.error} />;
  return <ProfileView name={profileStore.displayName} />;
});

runInAction מ-const ProfileScreen = observer(({ userId }: { userId: string }) => { const { profileStore } = useStores(); useEffect(() => { profileStore.loadProfile(userId); }, [userId]); if (profileStore.isLoading) return <ActivityIndicator />; if (profileStore.error) return <ErrorView message={profileStore.error} />; return <ProfileView name={profileStore.displayName} />; }); הופך את הרכיב לריאקטיבי: re-render רק כאשר מאפייני observer() שבשימוש משתנים.

השוואת ביצועים: MobX מול Redux

איך להימנע מ-re-renders מיותרים עם MobX?

React Context מבצע re-render לכל הצרכנים כאשר הנתונים משתנים, בעוד MobX מעדכן רק רכיבים תלויים. הטבלה שלהלן מציגה מדדים למסך פרופיל טיפוסי:

Context עבור DI

אנחנו מעבירים stores דרך React Context ללא חיווט Provider נוסף:

const StoreContext = createContext<RootStore | null>(null);
export const useStores = () => useContext(StoreContext)!;
// В App.tsx
const rootStore = new RootStore();
<StoreContext.Provider value={rootStore}>
  <AppNavigator />
</StoreContext.Provider>

mobx-react-lite יוצר את כל ה-stores ומעביר תלותים ביניהם.

הטיעון המרכזי עבור MobX

בהשוואה ל-Redux, אתם מקבלים פי שניים עד שלושה פחות קוד עבור אותה פונקציונליות. אין observable, אין const StoreContext = createContext<RootStore | null>(null); export const useStores = () => useContext(StoreContext)!; // В App.tsx const rootStore = new RootStore(); <StoreContext.Provider value={rootStore}> <AppNavigator /> </StoreContext.Provider> , אין נורמליזציה של store. עבור צוותים שמעריכים מהירות פיתוח על פני קפדנות, MobX מנצחת. התיעוד הרשמי של MobX ממליץ להשתמש ב-makeAutoObservable כדי לפשט את ההתקנה.

טיעון נגדי: פחות יכולת חיזוי. מוטציות מתרחשות ישירות, ללא לוג dispatch מפורש. לצורך ניפוי באגים, אנחנו מתחברים ל-RootStore או actionTypes.

מה כלול בעבודה

• הקמת mapStateToProps עם הזרקת תלותים.
• mobx-react-devtools + ה-hook mobx-logger.
• תבנית store בסיסית עם RootStore.
• אינטגרציה של StoreContext + useStores עם Babel (אם נדרש).
• בדיקות יחידה ללוגיקת ה-store באמצעות Jest (בדיקות טהורות ללא React).
• תיעוד על הארכיטקטורה והגישה.
• מדריך וידאו לצוות.
• תמיכה לאחר הפריסה (שבועיים).

תהליך העבודה

1. ניתוח דרישות וסקירת ארכיטקטורה נוכחית (יום אחד).
2. עיצוב מבנה ה-store והיחסים (0.5 יום).
3. יישום תבנית ו-store בסיסי (0.5 יום).
4. אינטגרציה עם מודולי האפליקציה (אימות, פרופיל, רכישות) — יום אחד.
5. בדיקות וניפוי באגים (0.5 יום).
6. מסירה והדרכת צוות (0.5 יום).

לוחות זמנים משוערים

הקמת ארכיטקטורת MobX מאפס — בין 2 ל-4 ימים בהתאם למורכבות האפליקציה. העלות מחושבת באופן אישי — צרו קשר להערכת פרויקט.

טעויות נפוצות ביישום

• שכחה לעטוף מוטציות אסינכרוניות ב-makeAutoObservable — מקבלים אזהרה במצב strict.
• שימוש ב-store אחד גדול במקום כמה קטנים — מאבדים ביצועים.
• אי שימוש ב-mobx לנתונים נגזרים — חישוב מחדש תוך כדי תנועה מאט את ה-rendering.

אם נתקלתם באחת מהבעיות הללו — הזמינו הקמת MobX turnkey. הקמנו MobX בפרויקטים עם 50+ מסכים ומבטיחים תאימות עם TypeScript, ניווט והתראות push.