Future Admin Generator: parse config using ts-morph to support inline functions and direct imports

[nsams]

The Problem

Currently the .cometGen.ts config files are evaluated as code. This has one major drawback: we can't parse inline code, as it will be executed, or, if it's a function definition, we don't know if it's inline or imported.

The Proposed Solution

Instead we parse the config file using ts-morph and iterate the resulting AST to get a json structure similar to before, but with the flexibility to parse for imports or inline functions.

Example, inline function (validate)

config with inline function:

                {
                    type: "text",
                    name: "title",
                    label: "Titel", // default is generated from name (camelCaseToHumanReadable)
                    required: true, // default is inferred from gql schema
                    validate: (value: string) => (value.length < 3 ? "Title must be at least 3 characters long" : undefined),
                },

generated code:

                            <TextField
                                required
                                variant="horizontal"
                                fullWidth
                                name="title"
                                label={<FormattedMessage id="product.title" defaultMessage="Titel" />}
                                validate={(value: string) => (value.length < 3 ? "Title must be at least 3 characters long" : undefined)}
                            />

Example, imported block

import { DamImageBlock } from "@comet/cms-admin";
// ...
{ type: "block", name: "image", label: "Image", block: DamImageBlock },

Disadvantages

Any other "a bit" advanced definition of config have to be explicitly implemented, as the config is not evaluated anymore. This includes any factories, helpers etc. Problem is that we can't use typescript to forbid them.

For example, the following needs custom (ast "walking") code to be supported:

const typeValues = [{ value: "Cap", label: "great Cap" }, "Shirt", "Tie"];

export const ProductsGrid: GridConfig<GQLProduct> = {
    type: "grid",
    gqlType: "Product",
   ///...
    columns: [
        {
            type: "combination",
            name: "overview",
            headerName: "Overview",
            minWidth: 200,
            primaryText: "title",
            secondaryText: {
                type: "formattedMessage",
                message: "{price} • {type} • {category} • {inStock}",
                    type: {
                        type: "staticSelect",
                        field: "type",
                        values: typeValues, //<< this identifier references a value defined in this file. NOT supported anymore.
                        emptyValue: "No type",
                    },

For example this would not be supported:

const typeValues = [{ value: "Cap", label: "great Cap" }, "Shirt", "Tie"];
typeValues.push("Foo");

Breaking change

The old import is not supported anymore, change:

block: { name: "DamImageBlock", import: "@comet/cms-admin" },

to:

import { DamImageBlock } from "@comet/cms-admin";
//...
block: DamImageBlock },

TODO

• implement missing json conversion parts
• allow usage of tsx, for example to use <FormattedMessage in validate
• use new way everywhere where we have imports
• typing of code-generation-runtime vs. config-definition is incorrect

Task: https://vivid-planet.atlassian.net/browse/COM-1626

[nsams]

here we also can keep the non-evaluated version (good)

[johnnyomair]

I believe the advantages of this approach outweigh the disadvantages. I'm not sure if devs ever want to code in config files. However, it's confusing that the file is a TS file, but operations won't work...

Maybe we could find a way to use both ts-morph and execute the file? I'm think of mocking/replacing the imports with stubs, like jest.mock does.

[johnnyomair]

Why is this change necessary? Was the usage incorrect?

[nsams]

yes, the first param is the row type: https://github.com/mui/mui-x/blob/v7.x/packages/x-data-grid/src/models/params/gridCellParams.ts#L18, the second is the value.

(this was swapped in mui-x)

[johnnyomair]

When do you plan to do this?

[nsams]

I don't have an idea yet how this could be solved. We can talk about it today.

[johnnyomair]

Do we still support imports here? Might come in handy if we want to reuse the same validation for multiple forms.

Also, you can use the FieldValidator type here, which includes allValues and meta in the function declaration.

[nsams]

Do we still support imports here?

yes, we do. It's just not visible anymore here in the types.

[johnnyomair]

I think this is a good solution to the problem 👍🏼

[nsams]

yes, it is pretty simple. But it doesn't support recursions (eg. for fieldsets)