[markbranly]

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.

[just_haug]

I suppose it depends on what you mean as a growing app. A few of the examples (https://github.com/yolmio/boost/tree/main/examples) are apps that you could easily sell as a freelancer/contract work.

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)

[markbranly]

> 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?

[just_haug]

The UI is essentially a node tree similar to react, defined in JSON objects.

This example (https://github.com/yolmio/boost/blob/main/examples/todos/sys...) gives a "lower level" example of a todo list that interacts with the database.

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.