Author here. I’ll try and fix this. I have a suspicion it’s the CSS glow behind the logo since everything else is the most stupid basic HTML you could imagine.
No, there are no dependencies. It has its own in-memory data structure, and ways to serialize it to other, more persistent, formats. I could imagine an option for more fully fledged RDBMSs being those persistence layers though.
Yes, one imminent idea I have is to codegen a .d.ts from an explicit schema (or even implied, from populated data). One might even be able to produce typed functions like `setPetsPrice(petId, price: number)` instead of `setCell('pets', petId, 'price', value: any)`.
By "reactive" I mean... if the data changes, the UI does (or at least, an event is fired, and then you can drive a React render, for example, from that). In contrast, you expect to have to poll an RDBMS for updates. An MIT team recently wrote an awesome essay on the same concept (https://riffle.systems/essays/prelude/), wrapping SQLite for the purpose.
With "data store", rather than "database", I'll admit I am hedging my bets. Through one lens, this library can look more like an app-level store in a classic React sort of way. Through another (most notably the table/row/cell structure), it looks like an RDBMS. I'm not ready to go all-in and declare it's a database yet. Such nomenclature comes with Assumptions™.
I actually love it when people invent things without full knowledge of prior art - a lot of innovation happens only when people aren't biased by what is already there. Perhaps if you knew all about PouchDB you might not have had enough motivation to do this, and then this gap of a relational reactive store would not have been explored. What you have done looks really great!!!
I do not want to take on CRDT lightly, since I want to make sure it doesn't balloon the library - it'd probably be an optional module. I feel like that's one of the next big things to tackle, so does v3.0 sound good? :)
In the meantime try opening up the drawing demo (https://tinybase.org/demos/drawing/) in two or more (of the same) browser windows and move things around. This is just via local storage but imagine how cool it would be to have that across broader collaboration...
I’m my limited experience, a reliable CRDT implementation necessitates a CDRT-first design baked into the core of any data / transaction model. Like I’ve heard some game developers say- multiplayer needs to come first because tacking it onto a single player game is a nightmare.
I need to revisit the space soon. Hopefully I’m wrong because I think CRDTs will play an important role in the next generation of applications. A smooth on-ramp for existing apps would do wonders for adoption.
Thank you. I figured that getting/setting/listening are the key primitives, and then the React layer (which is just one of many theoretical UI library bindings) can use hooks and components, or whatever, to simply wrap them. I'm not familiar with Dolt, but seems like I need to become so!
Cool! Please take a look and see if it works out. I should point out that the ui-react library (that provides React bindings) does _not_ depend on ReactDOM, so you can use it just as easily in React Native.
Logged with Brave support and as issue on the site’s repo.