Code Generation

Note

Iridium's documentation operates on the assumption you are generating type aliases for your forms, resources, tables, etc.

You DO NOT have to generate these type aliases for Iridium to function. If you prefer to use the more verbose definitions, you are free to do so. However, we highly encourage you to use the type aliases to keep your code clean and readable.

Iridium statically types form, table, resource, etc. elements for you based on the underlying struct you define them for. For example, a form based on a User struct will define a TextInput, Grid, Section, etc. with User as their generic type.

This can produce a verbose DSL that is ugly to look at, hence why iridium bundles in code generators for your resources to smooth over some visual noise when creating forms. The generated files are placed next to the file you create your form with the same name and a suffix of _iridium

Example

Simple text area definition before generation

// form.go
components.NewTextAreaResolvable[models.User]("text-area").
    Live().
    AfterStateUpdated(
        func(state string, ctx *context.FieldContext[models.User]) (string, error) {
            ctx.Set("name", state)
            return state, nil
        }
    ),

After type generation

// form.go
FormTextArea("text-area").
    Live().
    AfterStateUpdated(
        func(state string, ctx FieldContext) (string, error) {
            ctx.Set("name", state)
            return state, nil
        },
    ),

// form_iridium.go
type FieldContext = *context.FieldContext[models.User]

func FormTextArea(name string) *components.TextAreaResolvable[models.User] {
	return components.NewTextAreaResolvable[models.User](name)
}
//... More aliases.

Running your code gen

Please see the getting started sections for resource, tables, & forms, for the generation command to run prior to crafting your definitions.

FAQ

Why generics here?

Form elements, contexts, columns, etc. are statically typed to allow you to access the underlying struct for, say, an action, directly with full type support. For example, a RecordAction with type actions.RecordActionResolvable[models.User] will allow you to access the user struct directly when customizing your action's look & behaviour.

Tip

If this doesn't make sense, it doesn't have to! Experiment a little with forms, tables, resources, actions, etc. callback functions, and you'll understand the power of having a typed model within your request contexts.

Are these underlying structs GORM models?

Not necessarily.

Iridium aims to let you drive your forms, tables, etc. off of GORM models, or elements in an array, or file, api, etc.

Please see the drivers section in the documentation. The structs you define are interpreted by the driver you load for a particular resource.