Patterns for maybe or union types in React

[davetapley]

When it comes to 'doing control flow' (i.e. something is maybe or a union) there are two possible approaches:

1. Branch in a parent component and pass model instances of the model down to child components, or:
2. Never pass model instances as props and use e.g mobx-store-provider to inspect the state of the tree in each component.

Here's the problem:

With 1. Things get weird because, as I understand it, passing model instances leads to the kind of errors I'm running in to.

With 2. I want to do this:

const appStore = useStore(AppStore);
if (!appStore.whatever) {
  return <></>
}
// more logic

But then later in the component:

const foo = useHook(appStore.whatever)

And I can't do that because early return violates the rules of hooks.

---

I feel like 1. is the 'more correct' approach, but I keep running in to these kinds of problems:

• Editing a model is no longer part of state tree #912
• isAlive fixing strange Object that is no longer part of a state tree is being accessed issues #1544

[thegedge]

Don't you just love React? 😭

You could consider something like suspense, or depending on what kind of control you have over useHook, you could make it be able to work with null values, but the easiest approach is this:

const MyComponent = () => {
  const appStore = useStore(AppStore);
  if (!appStore.whatever) {
    return <></>
  }

  return <MyComponentInner whatever={appStore.whatever} />
}

const MyComponentInner = (props) => {
  const foo = useHook(props.whatever)

  // more logic
}

Breaking up your components in this way is my go-to when I need to get around the rules of hooks.

[davetapley]

I'm confused r.e. the that inner component pattern:
You are still passing an MST model into a component, which is what is to be avoided, no?

[thegedge]

You are still passing an MST model into a component, which is what is to be avoided, no?

Should be no reason to not do that. We do it all the time at my company 🙂

But if I'm reading things correctly, I think I missed the specifics of what you're working through. My bad! Sounds like you have a model instance that is alive when you render the component, but not alive sometime later. We definitely have had to deal with that issue too, but overall I don't think it's been a major source of pain for us. We have a few isAlive checks, but not many (and we have a pretty large codebase).

Maybe instead of talking in the abstract, you could provide a minimal example that shows the issue you're running into and we could work through that together?

The first thing that's popping into my head would be some kind of wrapper (like how there's observer for mobx-react) that checks all of the props for state tree nodes (isStateTreeNode) and then makes sure they're all alive. If not, the wrapping component returns a given fallback.

[OnkelTem]

Sorry if I answer out of place (maybe I didn't grab the core problem here).

Here's how we do it all the time with Mobx.

First, a couple of utility functions:

// A function to get rid of null context
export function assertContext<T extends object | null>(name: string, ctx: T) {
  if (!ctx) throw new Error(`Need ${name}Context.Provider`)

  return ctx as NonNullable<T>
}

// An optional utility to create store only one time
/**
 * Creates a class by its name and constructor parameters.
 * Useful for replacing lines like: `const store = useRef(new Cls(arg1, arg2...)).current`,
 * as it is not creating classes every render.
 * @param Cls classname
 * @param args constructor arguments
 */
export function useCreateStore<T, Args extends unknown[]>(
  Cls: Constructor<T, Args>,
  ...args: Args
) {
  const ref = useRef<T>()
  if (ref.current == null) {
    ref.current = new Cls(...args)
  }
  return ref.current
}

Store definition:

export class FooStore {...}
export const FooStoreContext = createContext<null | FooStore>(null)
export const useFooStore = () => assertContext('FooStore', useContext(FooStoreContext))

Store creation:

function App() {
  const fooStore = useCreateStore(FooStore, ...)
  return <FooStoreContext.Provider value={fooStore}>...</FooStoreContext.Provider>
}

Store usage:

export const FooComp = observer(function FooComp() {
  const fooStore = useFooStore(); // No need for null check, because context is guaranteed to be not-null

  console.log(fooStore.whatever)

  return (
    <div>
     ...
     {/* If you don't want to redraw the whole component */}
      <Observer>
         {() =>
           <Field value={fooStore.whatever}/>
          }
      </Observer>
      ...
    </div>
  )
})

As a general rule for nulls: we avoid using them.

• If a store seems to be needing a value, we can change its definition so that it could live without one.
• If an object type needs some required values, we apply Partial/PartialDeep so that we can assign {} to it.

Regarding the useHook()

As whatever is what we have control over, we could do this:

export const someModel = types.model('Recipe', {
  whatever: types.maybe(types.string)
}).views((self) => ({
  get whateverValue() {
    return self.whatever ?? ''
  }
})

...

function Foo() {
  const res = useHook(someValue.whateverValue)
}

What about stores passing via props?

We also do it all the time, they're just values.

Render or not to render?

It's sometimes difficult to think of a particular render if there is no value to display. Our approach is to still render something, then nothing. Because this way our UI will flicker less.