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. This is a nice to have. If you prefer to use the more verbose definitions, you are free to do so.

Iridium statically types form, table, resouce, 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 + 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[0])
            return state, nil
        }
    ),

After type generation

// form.go
FormTextArea("text-area").
    Live().
    AfterStateUpdated(
        func(state []string, ctx FieldContext) ([]string, error) {
            ctx.Set("name", state[0])
            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 type to allow you to access the underlying struct for, say an action, directly with full type support. For example a RecordAction with type actions.NewRecordActionResolvable[models.User] will allow you to access the 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.