mobx-react 6

[mweststrate]

Things to be addressed:

• switch to modern context (but keep same Provider / inject api) (Idea: introduce <Inject store>{(store) => ... component, to mimic React.createContext's consumer #448)
• plan strategy for hook based components (currently; use <Observer> or mobx-react-lite)
• make sure mobx-react is ready for concurrent react (primary concern: don't leak memory on early component disposal) -> opened #645 to address
• dispose components on error? (since upstream error boundaries should now handle them)
• merge TypeScript, MobX-React, and RefObjects #616 / TypeScript, MobX-React, and RefObjects #619
• stop lifecycle compatibility support
• split into smaller packages for Provider / inject / propTypes? nope, see #661
• verify devtools behavior (especially functional comps)
• verify component tree (names, provider & inject)
• Drop dependency on hoist-non-react-statics?
• rename entry files (Bundle names: using mobx-react instead of index #408)?
• use microbundle?
• update readme
• process review comments
• process TODO's

[danielkcz]

Hm, so you want to ditch the mobx-react-lite eventually? It probably should merge together at some point, but wouldn't it be too convoluted trying to support classes and hooks in one package?

[danielkcz]

Also, I convinced that we should teach people how to use React Context instead of including it in the package. For once it's super easy to do it and it doesn't seem it gives much of the benefit having it here. On the contrary, it would be harder to have proper typing for it.

[mweststrate]

@FredyC definitely not, the question is more, merge it into mobx-react, or make it be the next mobx-react (dropping propTypes, context, provider / inject and such). But I doubt we can loose the latter on the short term, I think most people still prefer the mobx-react api over React's own context api. So, yeah I am basically having the same questions as you have :)

[danielkcz]

Switching mobx-react to a new context API would make a bit nicer and smaller repo code for sure. However, as long as people will be using inject, they won't really know there is a different tech internally.

Personally, I don't see such a huge problem including one extra Provider in the tree to cover the transition. This isn't a first package suffering from that issue. But we should definitely make some migration guide explaning gradual adoption.

[urugator]

I would personally like to see prop-types/inject/etc in their own seperate packages.

[danielkcz]

@urugator Can you give some sensible reason why? I mean why is inject better for you instead of using context directly? Check this explanation if you haven't yet. Keep in mind that you cannot use decorators with functional components.

[urugator]

Where do I claim that I use inject or that it's better?
Let me reformulate: If there should be a custom inject utility, it should be in it's own seperate package (maintained by whoever needs it for whatever reason).

[danielkcz]

😄 Yea, I would probably agree, but that's not really the point of this issue which is more about migration strategy between two packages. Completely removing Provider/inject from mobx-react would effectively block anyone using it in existing projects.

I think that V6 should be more about those last two points from the checklist and if Provider gets the revamp along the way, that's more of the bonus.

[JabX]

While mobx-react-lite (or some other package) can keep the customs MobX hooks, at the very least both observer implementations should be merged into mobx-react's, since right now we can't use any hook in a "regular" observer function component (mobx-react wraps the function in a class).

Today if I want to start using hooks in my application I have to use both mobx-react and mobx-react-lite and use the correct observer for each use case, which is far from being ideal.

[danielkcz]

@JabX And you want to use classes for a new code? 😮 Cannot imagine why really, but I think it's a general direction of a whole React to leave this dark time period behind :) For any new component you can use lite package and eventually refactor class components.

I think that the main goal of mobx-react at this point should be to support class components as long as it's necessary while still being relevant in regards to the concurrent mode and other future features.

I could imagine that mobx-react could be a proxy for mobx-react-lite at this point. When it detects it's a functional component (does not have a constructor property), it would use lite observer directly, otherwise fallback to a current solution. It can also reexport all other hooks just for convenience so we don't need to use multiple imports.

In some long term, I guess we are talking years here, the mobx-react could ditch classes completely and become what the lite package is at this moment.

[JabX]

@FredyC At the very least I'd like to use hook-based components next to existing class-based components without having to use two separate implementation of the same function (observer).

And to answer your question : yes I'll probably keep using classes for new code, at least at some places where it makes sense to do so (large components, and even if it's frowned upon it's still very convenient to just extend an existing class component to override one method and keep the rest as is).

I don't really like the hooks API because it feels hacky at best, but I like what useEffect and useContext can do (this is so much better than what we have for classes), so I'll probably use them quite a bit. I wish the React team would backport some hooks features to classes, but anyway that's not really the question here.

[matsilva]

• plan strategy for hook based components (currently; use <Observer> or mobx-react-lite)

Does this strategy include a guide to help folks migrate?

[mweststrate]

I think the natural behavior consumers expect is import { observer } from "mobx-react" supports both hooks and classes (they are far from gone yet!). Whether that implementation is merged in or delegated is I think quite indifferent.

I think merging in (mostly to not duplicate facilities around it, such as devtools), and at the same time moving non-essentials to separate package (like proptypes (recommend: TypeScript) and inject (recommend: React.createContext)) is quite a viable approach