Find the best data structure for Create

[sekaiking]

The ultimate goal is to be able to Create anything in the most modular way possible:

Some concepts:

Core

• Project: a project can consists of many things such as (e.g. documents, widgets, devhub post, board...). A project is like a router that connects everything together.
• Widget: is the simplest thing a project can have.
• Document: a document is another simple thing and it's already implemented in Create, document is basically just a markdown text that can have a widget inside it.

Modifiers

• Template: Each thing (project, widget, document...) will need a template, a template takes the data from the thing and display it as needed.
• Theme: A modifier to templates, usually a CSS to customize the look of the template, can be used to change the colors, logo...

How we are saving data

• Project: ${accountId}/thing/${uuid};
• Widget: ${accountId}/widget/${name};
• Document: ${accountId}/thing/${uuid};
• Template: ${accountId}/widget/${name};
• Theme: ${accountId}/thing/${uuid};

graph TD;
    %% Core
    Project[Project] -->|can include| Document[Document];
    Project -->|can include| Widget[Widget];
    Document -->|can have| Widget;

    %% Modifiers
    Template[Template];
    Theme[Theme];

    %% Data
    Project -->|"`${accountId}/thing/${uuid}`"| SocialDB[(social DB)];
    Widget -->|"`${accountId}/widget/${name}`"| SocialDB[(social DB)];
    Document -->|"`${accountId}/thing/${uuid}`"| SocialDB[(social DB)];
    Template -->|"`${accountId}/widget/${name}`"| SocialDB[(social DB)];
    Theme -->|"`${accountId}/thing/${uuid}`"| SocialDB[(social DB)];

Loading

[elliotBraem]

This breakdown looks excellent. I am assuming that project would coincide with a bos.config.json in some ways?

A couple of insights & ideas to share:

Graph

Currently in create, we have the Project thing containing the references to the Document. This means when a document is created, we need to update the project to include the document, and update the document to reference the project. This was handled by an initial attempt to "plugins", but comes with some challenges:

1. You cannot create a document for a project unless you have write permissions to the project owner account.
2. Document ids and their nested structure in documentation

To address this, I think we could make use of the graph standard (like follows and stars) so that anyone can create and relate two things together. Then documentation is an object inside of the project that handles the curation/nesting of the document ids. So anyone can connect a document to a project (and we can filter to only show connections by "team members" or trusted accounts), and if someone wants to add a document to the official documentation, then it like a pull request to the project, to be approved by project owner

Provider & Adapter

Currently in create, we define handlers in the Provider and pass that down to any child that wants it. This has been a really cool pattern to explore and work with. Recently, using VM.require, I've been using adapters for abstracting custom logic. For example:

Provider:

// props.adapter = "efiz.near/widget/Module.Airtable"

const { get, create } = VM.require(props.adapter);

function getData(ref) {
    return get(ref)
}

const Children = props.Children || (() => <></>);

return <Children getData={getData} initialData={get()}  />

This way, you can swap out the adapter depending on where the data is coming from, without having to change anything within the provider. This is a simple example, but I've been following the same sort of idea for templates too. I use this adapter pattern in draw.everything.dev and you can test it out here, too