Some suggestions for mobx

[zq0904]

First of all, I would like to thank everyone for their contribution to this project and thank you for taking time out of your busy schedule to see my thoughts
I am a heavy Mobx user in React

1. Please keep decorator syntax. Its progress is quickly becoming standard and phasing out is not a good choice. Some libraries and frameworks are also used frequently/for a long time (e.g. Typescript, Nest).
2. Can we provide a method similar to pinia $patch for mobx (although I can implement it by myself, can it be built in?)

store.$patch({
  count: store.count + 1,
})
store.$patch((state) => {
  return {
    ... state,
    count: store.count + 1
  }
})

What really appeals to me about Mobx is the flexibility (multiple instances rather than centralized) compared to the simplicity (less boilerplate code) of other state management (redux).

[inoyakaigor]

What difference between

store.$patch({
  count: store.count + 1,
})

and

store.count = store.count + 1

[inoyakaigor]

@mweststrate By "autosetters" I mean autogenerated functions that can be used later. Something like:

class Store {
   awesomeField = 1
}

Store.setAwesomeField(2) // ← setAwesomeField is autogenearated (static?) function

Wouldn't that help solve the problem of boilerplate in stores?

[mweststrate]

Beyond that no type system would understand, the problem that it is holding the problem at the wrong end.

The proposal is a bit like saying: "unpacked rice is annoying to transport. Let's put every individual piece of rice in a tiny box". Yes, then it has been "packaged", but without really achieving anything. The goal is to get all the rice in a single box to make packaging meaningful.

There is no difference in behavior between doing a single assignment, and doing a single assignment in an action (except that it doesn't print a warning). If the goal is to stop MobX from printing warnings, the much simpler solution is to call configure({ enforceActions: "never" }).

However, it's not the store that needs to be batched, it's the events. E.g; only notify the UI once the execution of the onClick is completed. That is the batch, and that is the level at which actions should live. It has very little to do with stores.

E.g. onClick=() => { myStore.setA(3); myStore.setB(3) } would not be a proper batch, it would just be two separate batches, exactly the same as onClick=() => { myStore. a = 3; myStore.b = 3 }. To create a proper batch, you should batch at the level of the event handler, not at the level of the store: onClick=action(() => { myStore. a = 3; myStore.b = 3 }).

So autosetters would only supress the symptom; the warning we deliberately print, but it doesn't fix the underlying problem, except in the specific case where an event handler does precisely one mutation.

[zq0904]

Thank you for your answer

What I mean by this is that anything that is wrapped inside store.$patch will automatically call the action (this does not violate the original rule).

It seems to me that the following two code implementations are completely consistent underneath

  // before
  action(() => { store.a = 3; store.b = 3 })

  // after
  () => { store.$patch({ a: 3, b: 3 }) } // store.$patch Internal automatic action

  // before
  class S {
    @observable
    a = ''

    @observable
    b = ''

    @action.bound
    setA(a: string) {
      this.a = a
    }

    @action.bound
    setB(b: string) {
      this.b = b
    }

    @action.bound
    setAAndB({ a, b }: { a: string; b: string }) {
      this.a = a
      this.b = b
    }
  }

  // after BaseS contains the $patch implementation inside
  class S extends BaseS {
    @observable
    a = ''

    @observable
    b = ''
    
    // Large projects can be put into the store if the developer thinks it through and has enough abstractions  So that multiple logics can be reused
    fetchModifiedAAndB({ a, b }: { a: string; b: string }) {
      // Other business logic such as fetch and so on
      this.$patch({
        a,
        b
      })
    }
  }

  // Small items are unthought out without enough thought or abstraction. We can simply write them in the corresponding handle
  onClick={() => { store.$patch({ a: 3, b: 3 }) }}

It's much less boilerplate code and much more flexible and I don't have to go through the hassle of referencing action multiple times
I do currently use BaseS to mask the action layer

[mweststrate]

I think you can introduce your own utility function patch (store, values) { runInAction(() => Object.assign(store, values)) } and basically introduce that api. I dont think there is a point in introducing that into MobX, as it would be just another way to do the same thing.

Just again, to make sure you didn't miss my previous point; it isn't relevant whether the setters in your example class are actions, so no need to introduce boilerplate for that, it is important that patch is an action.

[zq0904]

Thank you again for your reply

[zq0904]

This is my implementation if you need it

  // src/common/ts/store.tsx
  import { createContext, useContext, FC, PropsWithChildren } from 'react'
  import { action, AnnotationsMap } from 'mobx'
  import { useLocalObservable as sourceUseLocalObservable } from 'mobx-react-lite'
  import { isServer } from './utils'
  import { MobxStateHydrationKey } from '@/types'
  import type { DepthPartial, PickFunctionName } from '@/types'

  type WithSetStore<CurrentStore> = CurrentStore & {
    setStore: <S extends Omit<CurrentStore, PickFunctionName<CurrentStore>>, K extends keyof S>(
      this: WithSetStore<CurrentStore>,
      payload: (Pick<S, K> | S) | ((prevState: Readonly<S>) => (Pick<S, K> | S ))
    ) => void
  }

  /**
   * 在原有useLocalObservable 增加setStore方法 及对应的类型校验
   */
  export const useLocalObservable = <TStore extends Record<string, any>>(
    initializer: () => TStore,
    annotations?: AnnotationsMap<TStore, never>
  ) => {
    return sourceUseLocalObservable<WithSetStore<TStore>>(
      () =>
        Object.assign(initializer(), {
          setStore<S extends Omit<TStore, PickFunctionName<TStore>>, K extends keyof S>(
            this: WithSetStore<TStore>,
            payload: (Pick<S, K> | S) | ((prevState: Readonly<S>) => (Pick<S, K> | S ))
          ) {
            const prevState = {} as S
            for (const key in this) typeof this[key] !== 'function' && (prevState[key] = this[key])
            const newState = typeof payload === 'function' ? payload(prevState) : payload
            Object.assign(this, newState)
          },
        }),
      annotations
    )
  }

  export abstract class BaseStore<CurrentStore, RootStore = null> {
    constructor(protected rootStore: RootStore) {} // 多个store通信
    /**
     * 借鉴了
     * @desc [react setState](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment-351013257)
     * @desc [pinia $patch](https://pinia.vuejs.org/core-concepts/state.html#usage-with-the-options-api)
     * @example
     * setStore({ count: 1 })
     * setStore(state => ({ ...state, c: new C() }))
     */
    @action.bound
    setStore<S extends Omit<CurrentStore, PickFunctionName<CurrentStore>>, K extends keyof S> (payload: (Pick<S, K> | S) | ((prevState: Readonly<S>) => (Pick<S, K> | S ))) {
      const prevState = {} as S
      // @ts-expect-error
      for (const key in this) typeof this[key] !== 'function' && (prevState[key] = this[key])
      const newState = typeof payload === 'function' ? payload(prevState) : payload
      Object.assign(this, newState)
    }
  }

  type StoreLinkComOptions = {
    isPage: boolean
  }
  const defaultStoreLinkComOptions: StoreLinkComOptions = {
    isPage: true, // 页面级store 当组件重新渲染会重新创建一个store实例
  }

  /**
   * 关联 store 与 组件 基于Context
   */
  export const storeLinkCom = <
    T extends new (...args: any) => InstanceType<T>
  >(
    Store: T,
    options: StoreLinkComOptions = defaultStoreLinkComOptions
  ) => {
    const _store = new Store()
    const StoreContext = createContext(_store)

    const useStore = () => {
      const context = useContext(StoreContext)
      // 其实这行代码永远不会触发 因为createContext初始化就有默认值_store
      if (context === undefined) throw new Error(`useStore 必须在 StoreProvider 中使用，来自 ${Store.name}`)
      return context
    }

    type StoreProviderProps = {
      [MobxStateHydrationKey]?: DepthPartial<
        Omit<typeof _store, PickFunctionName<typeof _store>>
      >
    }

    const StoreProvider: FC<PropsWithChildren<StoreProviderProps>> = (props) => {
      const store = _initializeStore(props[MobxStateHydrationKey])
      return (
        <StoreContext.Provider value={store}>
          {props.children}
        </StoreContext.Provider>
      )
    }

    function _initializeStore(data: StoreProviderProps[typeof MobxStateHydrationKey]) {
      // SSG和SSR总是创建一个新的 store 在客户端中（isPage true 每次创建新的 false 全局创建一次）store
      const newStore = isServer ? new Store() : options.isPage ? new Store() : _store
      // 如果您的页面有使用 Mobx存储的 Next 数据获取方法，那么它将 在这里 hydrate
      // @ts-expect-error
      if (data) newStore?.setStore(data)
      return newStore
    }

    return {
      useStore,
      StoreProvider,
    }
  }

  // 递归 Partial
  export type DepthPartial<O> = O extends object ? {
    [key in keyof O]?: DepthPartial<O[key]>
  } : O

  // 获取一个对象的函数名的联合类型
  export type PickFunctionName<T> = { [P in keyof T]: T[P] extends Function ? P : never; }[keyof T];

  // src/pages/testMobx/store.ts
  import { observable, computed, makeObservable } from 'mobx'
  import { BaseStore, storeLinkCom } from '@/common/ts'
  import { GetUserQuery } from '@/types'

  class TestMobxStore extends BaseStore<TestMobxStore> {
    constructor() {
      super(null)
      makeObservable(this)
    }

    @observable
    articleTitle = ''

    @observable
    articleContent = ''

    @observable
    getUserQuery: null | GetUserQuery = null

    @computed
    get articleContentLength() {
      return this.articleContent.length
    }
  }

  export default TestMobxStore

  const { useStore, StoreProvider } = storeLinkCom(TestMobxStore)

  export { useStore, StoreProvider }