Mobx-state-tree: question: using the type system for server-side io validation

[geekflyer]

Hi, I'm wondering if it is advisable to use mobx-state-stree only as a type system for validation of IO on the server side?

Generally I'm looking for a typescript compatible runtype type system to do that and currently I'm already using https://github.com/gcanti/io-ts in one node.js micro-service for that. I also know of https://github.com/pelotom/runtypes .

Comparing mobx-state-tree vs io-ts I found the following pros for each

mobx-state-tree PRO's

• it seems easier to define refinements
• every type can be named
• it can do some sanitization and casting (via defaults and lifecycle methods)

io-ts

• seems to have more type combinators (e.g. keyof)

I also wanna mention that I'm using mobx (but not mobx state tree) in the frontend - so maybe there could be some synergy effects.

I'm wondering on your thoughts on using MST for that rather unusual usecase @mattiamanzati or is it better to use io-ts ? Also wondering about the performance impact (using mst.typecheck to validate input). Maybe @gcanti also has some opinions on why io-ts is better for the use case :)

[mattiamanzati]

Uhm, TBH I would'nt use it for that, I'd go for either tcomb or io-ts from @gcanti !
The MST TypeSystem is inspired by his wonderful work :)

[luisherranz]

For what it's worth, I was about to suggest the same thing than @geekflyer.

For me, there is a bigger PRO: not having to learn/use two (or three) different type systems.

So, instead of using mst type system for the stores, prop-types for react and tcomb for the rest of the application, we'd love to use the mst type system everywhere.

[mattiamanzati]

Ideally there is a Type.validate(value) function, I'd like to expose that, but if you don't use mobx-state-tree, using MST just for validation is an overkill :)

[geekflyer]

@luisherranz I haven't really tried out tcomb, but does is that typescript compatible - i.e. can typescript infer / extract static types from tcomb (like io-ts and MST) (via some typeof operator like thing) ?

[gcanti]

@geekflyer tcomb predates io-ts (by over 2 years) and is a JavaScript library (though contains a definition file recently). io-ts has a functional programming flavour, is written in TypeScript and targets specifically TypeScript users

p.s.

Just a few nitpicks

it seems easier to define refinements

the API is identical

// MST
types.refinement(types.string, value => value.length > 5)
// io-ts
t.refinement(t.string, value => value.length > 5)

every type can be named

all combinators accept a name?: string argument

t.refinement(t.string, value => value.length > 5, 'LongString')

it can do some sanitization and casting

basically you can do anything in the validate body, included deserialization. Example: https://github.com/gcanti/io-ts#custom-types

[geekflyer]

@gcanti awesome, thanks @gcanti . I somehow must've missed the refinement operator when i started using io-ts 2 months back. The docs are a bit short on that combinator and what it actually does - perhaps an example of refinement would help (I may contribute one when i have some time). Anyways - thanks for all your awesome work!

[luisherranz]

My point was that once you are forced (in a good way) to learn the mst type system, it makes sense to use it all over your app, even for React.

If that's not possible, doesn't make sense or the mst type system is not efficient enough to be used everywhere, then io-ts looks like a great candidate for the job.

[geekflyer]

Since I'm not (yet) using MST, I'm good for now with using io-ts. But @luisherranz is right - if I would use it, it would be kind of redundant to define my types in multiple places with multiple type systems.

For me the problem is not the learning curve of multiple type systems, but rather that you have to keep the types between multiple type systems manually in sync which is effort and error prone.
When using io-ts I can use the same type definitions in the backend and frontend, but once I use MST I have to redefine my domain objects redundantly with another type system.

In theory one could probably write some sort of "converter" which does some introspection of an io-ts type and converts it to MST base models, but there should be a more elegant way. Is it possible to extract the MST type system into a separate library?