Making React Fun Again, with Sync [video]
youtube.com1 pointsby aboodman2 comments
```ts
// src/mutators.ts
import {defineMutators, defineMutator} from '@rocicorp/zero'
import {z} from 'zod'
export const mutators = defineMutators({
updateIssue: defineMutator(
z.object({
id: z.string(),
title: z.string()
}),
async ({tx, args: {id, title}}) => {
if (title.length > 100) {
throw new Error(`Title is too long`)
}
await tx.mutate.issue.update({
id,
title
})
}
)
}) * reason about what the right about of resources should be
* see opportunities for optimization
* forecast future need
* Having excellent domain knowledge and judgement
* Having the respect of the team, to settle disputes
* Solving problems when needed
* Hiring and retaining an excellent team
* Picking the right things to work on
I don't see the gotcha here. I don't care about the offline part. I mean I accept that some people do, but that's not where the value comes from for many major synced products like Linear, Notion, Superhuman.
> complicated/over engineered cache
Sync engines are nothing at all like a cache - that's the point.
They are a replica. Caches are by nature inconsistent. Every entry in the cache is from a different point in time.
Sync engines replicate a consistent subset of your database to the client as an atomic unit. This enables things caches can't do:
Whether these things are necessary depends on your application. But basically all productivity applications of any complexity keep re-implementing sync engines by hand so I guess most apps do in fact find them necessary.
Whether sync engines generalize is an open question. Is it hard? Yes. Is it a distributed systems problem? Yes! Is it worth doing? I think it is. Web applications often suck and sync engines are an important part of many of the ones that don't. I want to enable that experience for more apps without teams having to build it themselves.