Best practices: which is best 'helper functions' or actions/views/extent functions

[guigueb]

Both of the solutions below will work, but I'm not sure which is the best practices approach (or if it even matters).
This is - obviously - not the entire situation but it does illustrate the issue.
There is a function that relies on other functions, all of which rely on model props (maybe even model volatiles).
This could be coded two ways... and I'm not sure which is better/'best practice'.

Solution 1 (using actions/views/extent functions):

• Pros: uses MST structure/is more react/MST friendly
• Cons: has exports func1/func2/func3 that are only used by the final func4 export (func1/func2/func3 could be used at some time in the future but not at this time and may never be used)

.views(s => ({
     get func1() { return <aBoolean based on some logic using propA> },
     get func2() { return <aBoolean based on some logic using propB> },
}),
.views(s => ({
     get func3() { return <aBoolean based on some logic using func1> },
}),
.actions(s => ({
     func4() { <uses func2 and func3 to do something> }
}),

Solution 2 (using helper functions)

• Pros: only export what is to be used by those using the model
• Cons: not sure about MST performance/caching

.actions(s => {
     get func1() { return <aBoolean based on some logic using propA> },
     get func2() { return <aBoolean based on some logic using propB> },
     get func3() { return <aBoolean based on some logic using func1> },

     func4() { <uses func2 and func3 to do something> }
          
     return { func4 };
}),

I personally like encapsulation and like Solution 2 because...

• the outside world only sees what is officially supported (if there was a way to mark objects from an .actions/.views as private that would be great - enhancement?)
• all the logic for func4 is in the block, in solution 1 it could be scattered throughout the model.

Thoughts?
It would be really nice if there was a 'best practices' on this topic.

Bill

[coolsoftwaretyler]

Hey @guigueb - this is an interesting question. I would probably lean towards the first solution. I think it's more conventional as far as MobX-State-Tree goes because it keeps your computed values in views, and keeps your actions in actions.

Another issue with solution two is that I don't think we recognize the getter syntax inside the actions block. I made a CodeSandbox with a similar code sample, and when I change my helper functions to get [funcitonName], I end up with a bunch of errors. Go ahead and fork that if you think you can make it work. I'd love to see a different approach, and it's always great to have code examples in these kinds of discussions.

Even if you could make the syntax work (perhaps I've missed something), you'd have to handle caching yourself. Using getters in the views block will give you caching for free, with pretty reasonable default cache behavior.

So all that to say, the conventional, best practice in this situation is to keep computed values and actions separate, using the built in .views() and .actions() function in your model definition. That will look like typical MST code and provide you with built-in performance optimizations.

That said, there's a case to be made for your second option. I agree the encapsulation is great, and I think writing helper functions inside .actions() is perfectly valid.

If you think func1/2/3 should never be available to outside consumers, this is a great way to protect those from misuse. You'll want to either figure out, or ignore caching if this is a very important part of your design. Taking this helper-based approach will also keep your TypeScript types clean if you don't want people to see them on the inferred type of your model.

Last thought on best practices

This is a gap we have in documentation. If you browse through our discussions forum and issues, you'll find lots of people who really want more guidelines on the "best" or "recommended" way to use MST. In 2024, this is going to be a major focus for us as we improve our docs and community. I'll probably pull from this discussion as some source material.

[guigueb]

@coolsoftwaretyler
Thank you very much for your quick and good response.
I wish you had a tip jar - I'd give you 20%
BTW: your Sandbox demo'ed the issue well, get is not available on 'helpers' but is on function definitions in returns (see Volatile state)

There is a definitely a gap in docs, I spent hours on the internet and I found very little on 'helper functions', and nothing on best practices for this.
There is one example in the MST examples: BookStore
And the Volatile state with '.extend` docs looked promising.
But in the end here is where I got my answer.

My only real concern is making public objects.
Do you think it would be worth while asking for either...

• allowing 'helper functions' to be getters/computed?
• or allowing views/actions to be marked private?

[coolsoftwaretyler]

Hey @guigueb - happy to help! And yeah, we are going to be making an investment in docs this year. I expect you'll see more and more from me in the coming weeks.

I don't think there's a clear path forward to make those helper functions getters/computed values. They basically just end up in the closure of the return from actions or views, and I think it would take a high level of metaprogramming effort for us to pull those into the instance itself. Better to write your own caching mechanism inside the closure, than for us to make those choices on your behalf.

Marking views and actions as private is more achievable. I know a few folks on my team at work who would like this. I'd be happy to review a PR to that effect, but I would not ask the core team to champion it. Our priorities in 2024 are improving:

1. Docs
2. TypeScript
3. Performance

But I always prioritize community contributions above all else, so if it strikes your fancy, let me know. I can also give you a crash course on the codebase to help you get set up.