About Integrating with Ash
I’ve recently started getting acquainted with the Ash framework:
Since I’ve only scratched the surface so far, it’s very possible that there are better integration approaches than the one I’m currently taking. I’d really appreciate feedback from those with more experience with Ash.
Aurora UIX is currently tested to work well with Ecto schemas and Phoenix forms. Schema attributes are enhanced with UI-specific metadata that is not available in standard Ecto field definitions.
Sorting, filtering, and pagination are supported via options that can be updated dynamically through event logic.
Field / Attribute Differences
Aurora UIX relies on primitive and built-in Ecto field types to derive the initial UI representation of a field, and then provides mechanisms to further refine and enhance the UI characteristics of each field.
Ash’s attribute definitions, on the other hand, are extremely rich. Many of their options are well-suited to providing UI guidance (validation, visibility, constraints, etc.), and Ash also offers a broader range of types than Ecto.
This raises an important question: should I write a custom extension?
For now, I’ve decided not to. My goal is to preserve a clear separation between the model and the view. The idea is that a parser can extract most of the relevant UI-related characteristics from Ash resources, while still allowing overrides or refinements in a separate view module.
That said, if I’m overlooking important benefits or best practices here, I’d very much welcome your comments.
To support this approach, I’m working on a parser capable of reading Ash resources and translating their metadata into Aurora UIX’s existing UI definitions.
CRUD Operations
Aurora UIX currently relies on context functions—or manually defined functions—for:
- Reading (full list, paginated list, single record)
- Creating
- Updating
- Deleting
It expects the Aurora CTX pagination type and Ecto-like query options.
Ash, however, uses actions, which are powerful and self-contained 
. They can handle filtering, sorting, pagination, authorization, and more.
This leads to a critical crossroads, and I currently see two possible approaches:
- Write a parser that converts Ash actions into a set compatible with the existing Aurora UIX implementation.
- Refactor Aurora UIX to work directly with Ash actions and adapt pagination to use Ash’s native implementation when actions are involved.
Option 1 is the simplest, but I’m concerned it would limit or dilute a lot of the functionality Ash already provides.
Option 2 is more complex, but it would immediately unlock fine-grained control over what is shown or editable based on authorization policies and action definitions.
I’m very open to suggestions or insights on this topic.
