We are making the move to ts and I have some question for which I could not find any simple answers so far. So I hope to get updated opinion in this post.
1/ Is it useful to have both TS and simpl-schema ? it feels like they are partly redundant but simpl-schema has the validate method to ensure checking before inserting/updating data. However it seems very redundant to have both, especially when you have to declare both the types and the schema for all your collections. How do you handle this ?
2/ Do you have any up to date example app of meteor/typescript/react. While the basic boilerplate exists I could not find a little more advanced project that is using this stack. I don’t think any of the tutorials use typescript unfortunately.
3/ Any other ressources you would advice to jump (hands on meteor/react/typescript ressources) ?
There are definitely benefits to having these two in sync. I typically use a mix of technology to make this happen. Most recently I’ve been using GraphQL and Apollo to get those benefit, and sort of leaving Simpl-Schema/Collection2 behind for a bunch of reasons.
In another pure Meteor app, I used some really cool JSON Schema → typescript tools, with some runtime validation in methods running through ajv (validators generated from JSON Schema). I never set it up, but you can use the same JSON Schema in the Mongo tier, for additional type safety. Since the ajv validators were run in mdg:validated-method I had full stack runtime data validation which was in sync with my static type validation through typescript. All my validators and types were generated at once with a script. Wonderful.
I’d recommend one of these two approaches, instead of using Simpl-Schema/Collection2.
I completely stopped using simpl-schema and collection2. At first, I moved away just from collection2 (it has some edge case failures that were blocking work). I did that by moving from validating with collection2, to manually validating in my methods. All inputs ran through methods in my app, since I don’t use client side updates (and no one should), so it wasn’t a massive lift to change over.
But eventually, I wanted typescript, and once I figured out how easy it was to validate inputs manually, I started looking for alternatives to Simpl-Schema. I wanted to keep using the awesome convenience maker that is uniforms, so I explored the schema formats that they support, which is GraphQL and Simple Schema. Once I figured out how SimpleSchema worked, I rewrote my schemas in that, then set about generating types and validators from that. And it works AMAZINGLY well.
I’ve even gone in the other direction - take a typescript/flow document provided by an API vendor, generate JSON Schema from that, then generate a validator, to make sure I validate my API inputs (always validate your inputs! even from APIs).
None of that was possible with Simpl-Schema and collection2 - or at least, it wasn’t as easy (I still don’t know how to make types out of it, seems cumbersome). And this is not to disparage Simpl-Schema. I’ve used it for years, and it’s served my needs very well. I appreciate all the work that went in to it all. For me, it was just time to move on.
I think I have an entirely different approach, so let me share it as well.
No, it’s not redundant at all. As @rjdavid said, TypeScripts is for the programmer to prevent runtime errors (here: invalid data) from happening. Then the SimpleSchema is actually checking the data.
However, you don’t have to use SimpleSchema to do that. Even the Meteor-native check function may be enough in some cases, at least as the amount of validation you perform is relatively small. (It also lacks a proper error reporting and that may be needed, especially for the end-users.) If you’ll use @types/meteor, check becomes a handy type guard (source):
I do use it quite extensively, especially when the input is sort of “internal”, i.e., I don’t care about the error message.
I do agree, it’s awesome to have them in sync. But it’s also tedious. Some time ago I’ve experimented with automatic type inference for SimpleSchema (TypeScript 4.3 and SimpleSchema), but I didn’t use it in the end. And that’s not because it won’t work, but because I’m trying not to use SimpleSchema at all.
When it comes to GraphQL, I most often go with the schema-first approach, use GraphQL Codegen to create TypeScript types, and then implement the already typed resolvers. (Just keep in mind, that the validation in GraphQL is very limited: no “minimum length”, “maximum value”, etc. You have to do it with custom in-DSL directives or directly in the resolvers.)
That’s a great one, really! There are so many great tools to work with JSON schema (including uniforms), that it’s not only easier to work with but also definitely more future-proof. If it matters for you, you can also share the schema with 3rd parties, like external integrators.
What is more, you can use the same JSON schema both in-app (for validation) and directly in-MongoDB (for ensuring data consistency). Of course, the latter is something that should never be needed, but it’s good to have it. Check out Using built-in MongoDB schemas for more.
That’s one of the advantages of cross-technology standards. I can also recommend doing the opposite, i.e., write code that generates both the types as well as the schema (and then use the schema to create a validator, using ajv). One tool I strongly recommend is typebox.
I also have used it for years. And probably will for a couple more, in some projects. But personally, I do switch to JSON schema whenever possible. Same goes for aldeed:collection2 and universe:collection - I try not to have any sort of ORM/ODM at all and handle the raw (helper-less) objects instead.