Hacker News Reader

Comment by rich_harris | Hacker News Reader

Michel and I have been internet acquaintances for years, and we've even talked about this stuff IRL. MobX certainly isn't something we just somehow never learned about!

But anyway: it's absurd to compare this with React+MobX. MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, regardless of whether that's a boon to readability and maintainability.

By contrast, Svelte (and Solid, and other frameworks) understand signals on a much deeper and more optimal level. They're really not the same thing at all.

View on HN

> MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, regardless of whether that's a boon to readability and maintainability.

This is not true. MobX has had an `<Observer>` component for years now. You can be as fine detailed as you wish with rerenders in a larger component.

https://github.com/mobxjs/mobx-react#observer

MobX does not rerender entire components.

Unlike Redux at that time (~2016), it was a first approach where minimum rendering was happening effortlessly.

You can have a list of components where each component references a bit of global state and rerenders only if that bit changes, even though the list might have enlarged or other elements changed.

Last time I used it (2016-2020), they used all of the tricks of the trade, get, set object attributes, dropped decorators and it still worked the same.

Notice that you just said "You can have a list of components _where each component_ references a bit of global state". In other words, in order to avoid re-rendering everything, you need to have a component for each item in the list.

In React, the component is the unit of re-rerendering. MobX can't change that fact. The only thing you can do is work around it with hacks that imperatively update the DOM.

Yes, this clarifies what you've meant and I can see the case that is not covered with MobX+React but I assume it is covered by Svelte's runes.

You're saying that I can have the whole app written in a single file without any separation and the updates will still happen only in the place that needs it.

That makes sense. With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains html elements that are referencing the state.

>With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains html elements that are referencing the state.

It's trivial with MobX. The Observer component essentially gives you an "inline" component wherever you need reactivity, without the need to actually componentize.

i.e using a MobX State Tree store:

  const store = types.model('Store', { value: types.string }).create({value:'But I will!'});

  const Page = () => {
    return (
      <div>
        <div><h1>I won't rerender</h1></div>
        <Observer>
          {()=> { 
            const { value } = store;
            return (
              <div>{value}</div>
            )
          }
        </Observer>
      </div>
    )
  }

Cool, did not know that, last time I seriously used MobX was on 2016 primitives. But I see it works similarly to before. All of the accesses will be figured out during the first render.

Observer component is so simple. Just a deferred function invoke. Could have been done with 2016 primitives too.

Reply on news.ycombinator.com