Overriding Resolvers
Read Me
Overriding resolvers can be more complex and confusing than other parts of Iridium.
There is no, and likely will never be a definitive guide for overriding all our resolvers, considering they are all different, and the source code already does a better job of explaining how they work than we can in our documentation.
The tools to override our resolvers are there, but you should question whether you need to work in this area before you begin. Are you just trying to override a view, could an attribute work instead?
For Iridium's alpha, we're going light on documentation here. Please read our source code for more information! Visit our Discord for more help.
Resolvers take a resolvable variant and produce a concrete variant. As an example, they take a ResolvableInput[T] and produce a ConcreteInput[T].
Resolvers are registered at boot, before your application starts serving content.
Why would I want to override a resolver?
Overriding resolvers can be useful if you need full control over your components prior to producing their concrete form.
These are two examples:
- You need to mutate a component based on data from the current request, or elsewhere, that is not possible with the component's provided configuration methods.
- You want to forcefully add rules or alter how components are validated in a form lifecycle.
These examples may seem vague because we don't expect individuals who are not maintainers/plugin-authors to need to override resolvers. But the options are there if you need them!
Getting Started
To begin exploring resolvers, please fork our repository and visit our list of registered resolvers. Link. Click through to see where those constants are used to see their associated resolvers!
These resolvers can be overridden similar to views to allow to change how resolution happens. Simply redefine the bootstrap call with the same generics, and it should pick up your callback in place of ours. You can enable logging to see what's happening under the hood. Logging