Off-topic: Your platform looks like a really interesting tool for rapid-prototyping. How do you see in growing with the needs of the app?
Also, what is the obsession with a single file? Before I get to 1,000 LOC, I'm going to be looking to split it up into logical pieces—one for the DB setup, one for the UI, etc.—just to maintain sanity.
You can of course split up your system into as many files as possible, the emphasis on a single file is that now instead of your architecture, languages, etc. enforcing separate files and hampering reuse, you can organize it however you like.
I'm sure best practices will evolve overtime, but I've been alright with just a single file for apps in production (as long as the majority of components are made reusable)
> I suppose it depends on what you mean as a growing app. A few of the examples are apps that you could easily sell as a freelancer/contract work.
The examples are interesting but what I don't see in your docs is how to control UI. Is that driven entirely by data types? What happens when an app wants/needs novel UI/flow?
But excerpted the below demonstrates the state approach:
nodes.state({
procedure: (s) =>
s
// A scalar is a single value
.scalar(`input_text`, `''`)
// Queries the todo table from the database and puts them in a ui table
.table(`todo`, `select * from db.todo`),
children: [
// like react, controlled input
components.input({
value: `input_text`,
on: { input: (s) => s.setScalar(`input_text`, `target_value`) },
}),
components.button({
on: {
click: (s) =>
s.serviceProc((s) =>
s
.startTransaction()
// Inserts into the database using the scalar defined in the ui
.modify(`insert into db.todo (title) values (input_text)`)
.commitTransaction(),
),
},
}),
],
});
It defines a node hierarchy with ui state (tables) and that state is populated from the database. The serviceProc is able to modify the database with data from the ui state.
There is nothing special about any of the components and functions I call in the examples, there are really just creating node hierarchies and objects. It means that you aren't limited to kinds of UIs you can create and you can create your own functions that just take in data and return arbitrary node hierarchies.
I assume so, I have seen a few people make SQLite run in the browser against IndexedDB, but I haven't personally seen anyone build one from scratch for it.
After 6 years of work we are publicly releasing Yolm (https://yolm.io) in beta.
This is the first of three technical articles going in depth into the architecture of Yolm.
I will be here to answer any questions and you can contact me on twitter at https://twitter.com/just_haug
Also if you just want a quick overview of what Yolm can do, watch this video: https://youtu.be/GHzNIX7kdSw
If you want to try out Yolm for free, follow the instructions at https://yolm.dev/tutorials/quick_start/