TinyBase: A JavaScript library for structured state

I agree with your very final point. The same might be true of the undo stack implementation too - at some point the usage patterns might invalidate some of my performance assumptions.

(That also spits out ascii charts to visually make sure there are no complexity explosions. See https://tinybase.org/guides/how-tinybase-is-built/testing/ for example.)

As for maintainability... I have no data yet, since it's a couple of days old ;)

class Foo { foo() {} #bar() {} }

Becomes:

class f { foo() {} b() {} }

Combined with any type of compression the negligible difference is eliminated. Though it is true that static functions might be more optimisable in some cases, I'd say that on balance, the effect on maintainability is too significant for the returns. I'll take DI and testability over maybe a few kb difference

Quite possible. This was a journey! https://tripleodeon.com/2022/01/software-without-compromise/

When I first started thinking about this project, classes still meant a bunch of transpilation overhead (which dates the origin story!). I persuaded myself that plain old objects with TypeScript interfaces would strike a better balance between performance, size, and developer experience.

So I ended up with a pattern like:

  const longMethod1 = () => {...};
  const longMethod2 = () => {...};
  return {longMethod1, longMethod2};

I believe Orbit.js was inspired by Ember Data, as I know Dan Gebhardt is involved with Ember.js and https://jsonapi.org

1. Batching, to avoid network waterfalls (a consequence of network use being more expensive on clients than on the server).

3. Data dependencies, so the framework knows how to stitch queries together when batching them.

3. Consistency, so all UIs update when an update comes in (a consequence of SPAs being long-lived, as opposed to the typical stateless server request).

These all take some code/framework overhead. It’s valuable to pay that cost on clients, but is unnecessarily verbose for the server.

People have been trying to unify local and remote function calls for years, and it’s a similar problem: the two are fundamentally different.

1: https://github.com/tonsky/datascript 2: https://www.datomic.com/ 3: https://github.com/metasoarous/datsync

Combine it with the various JavaScript ORMs and you have a nice developer UX.

I’m waiting for someone with more time than myself to build a syncing feature on top of SQLites Sessions[2] so that changes locally are synced back to the server.

(Feel like I’m a cheer leader posting this comment every week)

0: https://sql.js.org/

1: https://github.com/jlongster/absurd-sql

2: https://www.sqlite.org/sessionintro.html

This idea got muddled when people started making websites as SPAs, which necessitated SSR for SEO and first-page load. Now you blurred the lines between client and server, otherwise known as isomorphism, which is a good sounding word for a bad idea.

You can see this in action in the TinyDraw demo: https://tinybase.org/demos/tinydraw - make some changes, refresh the page, even open it up in two windows of the same browser at the same time.

For a snappy data-centric app, you pretty much need your entire app logic to run client-side.

Everyone always ends up with this terrible denormalized client-side cache with duplicated Server side logic.

What you really want is the exact same db running server-side and client-side.

I thought for a while this would be an sql db but now I think sql and the relational model is the wrong approach for web app data as they are inefficient for watching queries and syncing.

We did eventually add a `createEntityAdapter` API to Redux Toolkit [0] [1], which handles the process of storing items in normalized form and provides "CRUD"-style reducers for typical operations on that data, but it doesn't provide any support for managing relations specifically.

That topic _has_ come up a few times recently, so I've been contemplating that as a thing we might consider trying in a future version of RTK.

If folks have thoughts on what that API's requirements might look like, I'd be happy to start discussing that over in the RTK repo!

[0] https://redux-toolkit.js.org/api/createEntityAdapter

[1] https://redux.js.org/tutorials/essentials/part-6-performance...

I think for now you'll need to create your own local type definition that models the data you know is in the Store. But let me think a bit more about this.

  Grow store, different table to index with multiple row count, µs per row
  First: 16.3 µs per row
   Last: 3.61 µs per row
    Min: 2.76 µs per row
    Max: 29.89 µs per row
    Avg: 7.33 µs per row

        90.00 ┼───────────────────────────────────────
        84.00 ┤
        78.00 ┤
        72.00 ┤
        66.00 ┤
        60.00 ┤
        54.00 ┤
        48.00 ┤
        42.00 ┤
        36.00 ┤
        30.00 ┤╭╮
        24.00 ┤││     ╭╮
        18.00 ┼╯│     ││         ╭╮
        12.00 ┤ ╰╮   ╭╯│    ╭╮   ││          ╭╮
         6.00 ┼──╰───╯─╰────╯╰───╯╰──────────╯╰╮──╭───
         0.00 ┤                                ╰──╯

When not using React or Vue, people used to these conventions will not know how to properly pass state between objects. This library is for them. It really offers little more than `window.pets.dog.species = "poodle"` would offer but because it is a library it feels "less hacky".

[1] https://tinybase.org/guides/relationships-and-checkpoints/us...

This is a stepping stone. A reactive, relational store is very useful, something I've been thinking about for a long time.

This allows you to wrap a batch of mutations together and then the fully reconciled change events are all fired together at the end. Apparently I could do a better job of marketing this secret feature :)

As another commenter has mentioned, there are also 'checkpoints' that let you create a stack of points in history to undo/redo back and forwards through. https://tinybase.org/guides/relationships-and-checkpoints/us...