Question

[aap82]

Before I say anything there are two things you must know: 1) I have no professional background in programming, web design, theory, or anything having to do with code. I'm purely self taught (less than 8 months) in this regard. Second, I've had quite a bit of scotch (half bottle of Macallan 12-year) this evening, this after a few bottles of wine; so I may have missed something obvious, and I truly apologize if that may be the case.

But, is there a reason you're passing all of the stores (the entire store object) around with the router store and its routing functions? I'm asking because in your example you placed the component as a child of Provider, thereby allowing it and every component that so chooses to gain mobx store access through context (@observerable).

So, if I may offer a feature request: removing the single store concept and passing multiple stores to the component through rest properties , allowing mobx-router to pick up the router store, and then, in the view config section, one could provide an array of stores for each route. (I saw how this is currently passed to director.js, but can easily be stripped out, no?).

Why an array of stores? Then you could easily write a higher order component and decorate each of the routes/components with only the stores they need that have been defined.. For some reason, I thought this would make the whole application easier to reason about.

But I know i'm coming from a different place here. I don't work for a tech company, and I don't write tests or comments, but for I like mobx, and I read Michael's article, and it made sense. So, thank you.

[kitze]

First of all, that's the best GH issue intro I've ever seen. Enjoy your drinks! 😅

Right now there's not a single and best way of modeling a mobx store, so everyone has their own solution.

There's currently an open issue about supporting multiple stores but I would have to explore this carefully and figure out what would be the best way to implement this before proceeding.

In all of my mobx apps I'm using a single store object so that's why I went with this approach for the router. (example)

One question I have about your suggestion: how would the hooks (onEnter, onExit, etc.) receive the store as an argument if it's not passed around? (keeping in mind that import store from 'config/store.js' at the top of views.js is not a solution that everyone would want)

When I have some more time I'll dive into this issue further and see if I can make it fit for everyone.

Btw: mobx-state-tree will be released soon so it may also shake things up a little bit.

[aap82]

I am enjoying them, but for how much longer, I do not know. Your one question seems to relate directly back to your second sentence to some extent, does it not? I'm having the hardest time trying to figure out how I should structure something with mobx as a store provider.

So, while I think about how to answer your question about hook, may I ask what does one expects to with hooks? Are they only API calls? or clean up of event handlers? I know how and why I want to use them, but I do not know how they are used in practice.

I'm going to save the mobx-state-tree question for another day. I'm not sure how I feel about it yet. I haven't seen the word cursor yet, so, that's a positive.

[kitze]

Yeah, mobx-state-tree is developed so there can be a more opinionated way of shaping the state tree in mobx (hence the name). For now everyone is going freestyle.

The hooks are using the store argument so they can trigger changes in the store directly, instead of relying on React lifecycle methods.

Example here: https://github.com/kitze/kitze.io/blob/master/src/config/views.js#L20

[aap82]

I came across and began to use baobab-react before mobx, which allowed me to do nearly the same things in a cleaner, structured way and was performant enough.

But if felt heavier, because I thought I was dragging my entire state tree around with me everywhere. That's what drew me to mobx, the ability to break up the state tree, or at least its store representation, into smaller abstractions attached to components.

just the thoughts of a drunken american...