Add Zod and Effect Schema support for better DX about tinybase

[gunta]

My new stake is: Add schema adapters for the following libraries

1. Zod

• The mainstream one
• Everyone knows how to use it
• Simple
• Zero learning curve

2. Effect Schema

• The hottest one
• The most feature rich
• The one used the most in Local First libraries (for a reason):
  • LiveStore
  • ElectricSQL
  • DXOS
  • Jazz
  • Automerge
  • Evolu

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.

Star History

Effect 3.0 GA has just been released so its getting traction.

[jamesgpearce]

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...!)

[jamesgpearce]

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!

[gunta]

Ok, I'll try that one! Thanks

[jamesgpearce]

Assuming that's an OK approach, can I close out this issue?

[gunta]

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:

• Zod schemas
• Typebox schemas
• Valibot schemas

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;

[MentalGear]

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.

[gunta]

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.