Resolution Pipeline

Note

This documentation is completely optional. You can easily override your components without understanding our resolution pipeline. We recommened going there first.

If you need a small tweak, perhaps a simple attribute will suit you better.

Once/If you get into a deeper layer of customization, understanding a form's lifecycle can help you change Iridium to fit your requirements.

Iridium uses a structured way to inject the current form context & request information into your resource, form, table, etc. definitions at runtime to eventually produce a final .templ component that can be rendered to the front-end.

This is what allows you to, for example, change the label of a text input with the LabelFn callback like so

TextInput("name").
    LabelFn(func (ctx FieldContext) string {
        if ctx.Model.Name == "Joe" {
            return fmt.Sprintf("Enter your name %s", ctx.Model.Name)
        }
        return state, nil
    }
)

Behind the scenes, iridium registers how it will create the FieldContext for a text input with the type of models.User, creates that at runtime, and then injects it into your field element to allow for user customization as shown above (contrived example).

Since the context is typed with your underlying struct, you're able to access for example the underlying model through ctx.Model with full type support.

Three stages

Form fields, table columns, etc. go through three stages to eventually be rendered to the front end. The translation layer between them is overridable, allow you to customize your components' journey along the rendering pipeline. You can change:

1. How you generate the context for a resolvable variant prior to injection.
2. How you convert between a resolvable variant to a concrete variant.
3. Which view variant you'll use for your concrete variant.

End users mostly interact with the resolvable variants of components, like the FormInput whose type is actually components.InputResolvable[T]. That is where you can define static variables for your label, or a callback to define the label at runtime for example.

Cavets

There are some exceptions to this.

1. To prevent every single form element on the page from regenerating the same context struct over & over (which would all have the same state), they are passed a context struct created by the form's resolvable variant. So for right now, you're not able to define how the field context gets generated on an individual basis for form elements (could easily be a thing in the future if really needed).
2. Some content on the page just simply has no resolvable variant, like the root template. The root template defines your base html file (your scripts, where to load css, meta tags, etc.). There is no resolvable form for this, since you can't change its fields at runtime (yet). So you're only able to change the concrete -> view varient pipeline.
3. Some other content is just completely static. You're able to override these as well, but with no concrete or resolvable forms, you're just swapping the .templ component. This is for example, the built-in theme switcher button on the nav.

A Resolvable variant

A Concrete variant

A View variant