Developer experience Feedback list

[CallmeT-ty]

• Our generated code was currently being ignored by Git, So you couldn't see changes to the generated code when modify input code. We've stopped ignoring the generated code and allow it to get commited to Git so you can track changes more easily
• We want to get to a point where you can opt out of code generation and/or commit code you've adjusted by it not being overwritten in the generation process.
• Reworking the bundling of packages (Ongoing)
• Not seeing all document models as options for creating a New Document:

Solution underway

the new setup will work like this:

by default, the only document model and editor that are included is the document-model and document-model-editor which are used for creating other document models.

connect then will look for a powerhouse.manifest.json file in the project, and that file will specify the document models and editors to be loaded and shown as options.

Using this manifest file will prevent the problem where small naming differences cause document models and editors to not be found — the exact locations and names can just be specified in this file

• Connect still struggles to rename the type, extension and name of my document model documents. This causes me to need to manually find+replace hundreds of instances of my document name within the code and within the file structure every time I need to export my document from connect.
• Package scripts and snippets of code are still frequently written in a way which does not support windows execution.
• We'd like to offer more clarity on where backend code like Reactor fits in to the new scheme, it has either been omitted or its considered one of library/apps, but I'm not sure. I would like to move as much business logic out of Connect as possible and into Reactor, and serve a legible API from reactor. TL;DR Reactor should provide API endpoints to call operations on documents without the client having to calculate the result of the operations. Connect should be a GUI and nothing else.
• The code in /src is so tightly coupled to the code in /gen that there is no reason for one to be considered "editable template" and the other not to be. The removal of /gen from .gitignore is a good first step for quality of life, but I think we should rethink it entirely - Currently, essentially all of the actual business logic of a document model is the reducers and typescript/zod types. Everything else is only serving to make developing those reducers and types a royal pain in the fucking ass.

Click here to expand ideas of zktruth

There are two different worlds depending on what we need to do with reducers:
If we need reducers to be turing-complete and do anything like they are now, they will need to be published and deployed/distributed no matter what.
If we can restrict reducers to being declarative, then a document model could completely define itself by providing field paths and conditions/validations assuming a domain language or runtime that can do basic calculations.

Eg. for CUE (an OSS data validation language and runtime) a document model schema could look like:

#LineItem: {
    id:          string
    quantity:    number & >0
    unitPrice:   number & >0
    taxPercent?: number & >=0 & <=100
}

// Derived totals (computed fields)
#Invoice: {
    lineItems: [...#LineItem]
    subtotal: sum([item.quantity * item.unitPrice for item in lineItems])
    tax: sum([
        if item.taxPercent != null {
            item.quantity * item.unitPrice * (item.taxPercent / 100)
        } else { 0 }
        for item in lineItems
    ])
    total: subtotal + tax
}

. . . and then operations can be scoped down to only modifying underived fields, and the document model itself actually expresses what is going on with it rather than what it does now -- which is hope to coincidentally match the names and types of code being written and published god knows where.

Then everywhere else, the types and operations can be derived directly from the document model itself. We can feed them to codegen once to create zod types to aid editor development, but then for every other purpose they can be loaded directly from the document model by Reactor without any need for publish/distribute/maintain. Reactor would be able to - at runtime - load and serve API endpoints for any document in the drive (starting with the base document model, which can be distributed with Reactor).

We would still need to publish the editors, either maintaining a library of them compatible with different models that can be installed as needed or by deriving the package which needs to be fetched within the schema also. But advantageously these editors would not necessarily need to be updated and republished for every change to a document model as long as they can read and call the Reactor API sanely
In an extremely optimistic future where we have a component/style library we're happy with, you can almost imagine being able to return hypermedia from Reactor based on the api/schema of the document model