Instinctively what I wanted for the dynamic tree is a React-like data flow with the view as the function of state.
Given a data model of the tree of nodes:
const tree = [
{ type: 'text', value: 'Hello, world' },
{ type: 'text', value: 'List', children: [
{ type: 'text', value: 'Item 1' },
{ type: 'text', value: 'Item 2' },
] }
]
(Looks similar to Freewheeling Hypertext. I have a hunch that HTML is actually a dialect of Lisp.)
I want to render it into an existing DOM element, like:
render(App({ tree }), view)
The app can have “actions” to manipulate the tree, like create/delete/edit/search nodes. Each node could have actions too, like move up/down. And all actions produce new state, which re-renders the application, efficiently updating the changes.
But React has a big interface and file size, it’s not fully understandable by a single person. The compromise I settled on is using Preact and its Signals library.
Signals are reactive primitives for managing application state.
I “prebundled” these (using Bun’s built-in bundler) as a standalone library in a single unminified file, meact.js. That way we don’t take its internal logic for granted, all code is readable and forkable if needed.
I decided not to use JSX syntax, which requires a build step. Instead I’m writing the view by hand, with h() as shorthand for createElement.
h(tagName, attributes, ...children)
Sure is a Lisp-y looking shape. It may not be a familiar syntax as:
<tagName key={value}>
{...children}
</tagName>
But I think any verbosity is worth it for not needing a build step. It’s simpler, more immediate, with fewer layers of abstractions.
So now there’s a minimal dynamic self-editing tree with view and actions to modify its own state.
Just the first few steps already needed design decisions that are subjective, opinionated, arguable and questionable. It kind of feels like I’m doing things with one arm tied behind my back, intentionally limiting my usual toolbox to a small set of portable tools.
Next I want a tiny Markdown parser (that also supports a subset of HTML) as a single standalone library.
I’ve been playing with OPFS (Origin private file system), a web API for a virtual file system in browser local storage.
This would be convenient for local-first data, but requires a local server (or remote one with HTTPS). It won’t work with an HTML file opened directly.
localStorage probably works with no server - but it’s more primitive and slow. So again progressive enhancement would be a good approach.