Open gunta opened 4 months ago
Did you see this? https://tinybase.org/guides/schemas-and-persistence/schema-based-typing/
When you use the 'with-schemas' versions of the definitions, you get inferred APIs based on the JSON.
Let me know if that is what you had in mind or how it could be improved!
Ok, I'll try that one! Thanks
Assuming that's an OK approach, can I close out this issue?
Ok! It worked :)
However I was thinking of making the schemas more "modern" and "common" along most used practices around the corner.
There are multiple ways to write a schema in TS, and it may be a good idea to support multiple ways since it is common for the developer to prefer the syntax that one is already using in the project.
For instance, Drizzle supports three different schema tastes:
So it might make sense to support all, or some of them.
Also, considering that TinyBase schema types are very simple, perhaps doing the schema typing as Typia or Deepkit might work well enough.
So instead of having this:
const tablesSchema = {
pets: {
species: {type: 'string'}
sold: {type: 'boolean'}
total: {type: 'number'}
},
} as const;
We could just have:
const tablesSchema = {
pets: {
species: string
sold: boolean
total: number
},
} as const;
Providing zod
integration would be much appreciated. Not only is it probably the most feature-rich and most popular validation framework, but many automatic FOSS form kits (e.g superforms, formsnap) exist that make it easy to use the same schema seamlessly on the front- and backend, streamlining the whole application code and cutting overhead tremendously.
My new stake is: Add schema adapters for the following libraries
Social proof: https://x.com/schickling/status/1761707815016559048
Since Effect Schema has became the defacto standard for the data layer in LoFi libraries, I believe it to be a no-brainer to add support for it.
Effect 3.0 GA has just been released so its getting traction.
OK, I think we could have a go at this, though of course it will be a limited dialect of what most of these other schemas are capable of. One question is whether this should be a dev-/build-time process (to create a TinyBase schema from these others) or something that can just be handled at runtime. I need to get familiar with all of these and what common pattern might work. (Hence I'm going to say it'll be after 5.0...!)
One question is whether this should be a dev-/build-time process (to create a TinyBase schema from these others) or something that can just be handled at runtime. I need to get familiar with all of these and what common pattern might work.
Looking at how other libraries solve the problem might be a hint: Drizzle creates a runtime extension for each schema validation library.
https://github.com/drizzle-team/drizzle-orm/tree/main/drizzle-zod https://github.com/drizzle-team/drizzle-orm/tree/main/drizzle-typebox
If performance becomes an issue, a dev/build time process can be added later.
I am going to focus on schemas in 5.1 and 5.2. Hang in there!
Is your feature request related to a problem? Please describe. The whole thing of defining a schema in a JSON file its a bit outdated compared to modern solutions.
Describe the solution you'd like We are talking about something along the lines of [Kubb's Infer], Typia, Zod and Effect Schema.
This would definitely improve the DX as a whole for TypeScript developers.