Clean Typescript types for snapshots

[tibotiber]

Hello, getSnapshot's return value is a ModelSnapshotType. I was wondering if there is any helper or technique to clean that type into something that uses Typescript's built-in types only? This would be useful to expose the typed return value to users of a library that's MST based without exposing MST's complexity to the users.

[coolsoftwaretyler]

Hey @tibotiber - so sorry it took so long to get back to you. I'm not sure if this is still relevant, but you might consider using a utility like SnapshotOut.

If that doesn't work, could you maybe drop a code snippet so we can play around and try to get a better answer for you?

[tibotiber]

Thanks for the reply @coolsoftwaretyler. So the story is quite similar with SnapshotOut in my experience, I use a lot of these types at the data storage/retrieval level, but it also results in "MST flavoured" types, not just "vanilla TS" types.

The idea here is i'm starting to expose some of the data through a user-facing library and I want them to see vanilla types, not types inherited from MST. The longer approach I use is to write a view on the models to roll up my own "JSON export", resulting in the types i'm looking for. I do this in some places where I want something slightly different from a pure snapshot of the model and it's all good. In other places where my JSON export is pure snapshot I was hoping to avoid that work and get vanilla types easily. If that's not available I can always fall back on the manual export method.

Curious though, would it be hard internally to generate non-MST flavoured types for the snapshots?

I'm hoping i'm clear here, not too sure what vocabulary to use. Happy to explain better if it's not clear.
Thanks and take care.

[coolsoftwaretyler]

@tibotiber - you're totally clear. This makes sense.

I don't have a better idea at the moment than what you're doing. And I'm not sure if this would be easy or hard. My gut reaction is "hard", because the internal TypeScript system in MST is pretty complex.

But we have lots of TS helpers that are actually pretty straightforward, so maybe it wouldn't be too bad.

I won't be able to prioritize this work, but I'm doing some exercises to really dig deep in our internals, and if I come across a good idea, I'll open a PR and let you know.

If you want to move this forward, I would prioritize any PR review for something you put together on your end (or if anyone else sees this and wants to give it a go).

Sorry I can't be more helpful at the moment.

[tibotiber]

Thanks for the super transparent answer. I get the prioritization call here and will expand on my current approach then. Nothing to be sorry for! This is an amazing lib and I truly appreciate the work that's been put into it.

If you ever get to this and want some feedback/testing, feel free to ping me. On my end, I think this is something that would be too complex and require a time investment I can't afford, so I won't be opening a PR. If anyone gets to it, ping me for thoughts ;).

Not sure what's your workflow, but from my end feel free to close the discussion. Take care.

[coolsoftwaretyler]

Awesome! I'm going to leave this open because it's a great idea, and I want folks who are looking through the discussions/issues to consider picking it up of their own volition if they come across it.

We are balancing performance improvements with TypeScript improvements, so this is great input for that, and hopefully I'll be able to have a better tool for you in the coming months. Or perhaps someone else will.

Thanks for letting us know and for understanding. We are out here tryna make the best library we can for the community, but only so many hands on keyboards haha.