2,508 karma · joined March 11, 2009
https://x.com/jamespearce https://tripleodeon.com
I wonder if I should have a font-weight (or -family) toggle alongside the dark mode setting. Would be a shame for people to miss out on reading about the software because of the typography!
Of course it would be pretty easy/fun to persist your TinyBase content into a SQLite database, or pull a dataset from it. The demos load up TSV but you could easily do something similar from an actual database somewhere.
At least, once I got the bundler to be happy about the export format! Please see https://github.com/tinyplex/tinybase/issues/17#issuecomment-...
“I only have a minute left, which is more than enough time to build the undo stack”
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 ┤ ╰──╯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.
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...
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.
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};
These 'methods' can still call each other by name, and it minifies like a champ.(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 ;)
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.
One of the interesting things about this project was the reality (and curse) of writing software when you don't have any constraints. I wrote a little bit about the experience here too: https://tripleodeon.com/2022/01/software-without-compromise