If you aren’t already familiar, Ash has a lot of introspection tooling: Ash.Resource.Info — ash v3.29.3 I’m not sure what you meant by “parsing,” but almost any data you could want about an Ash resource is readily available via the Info API.
Regarding an extension, I would advise strongly against building a resource extension for UI (I’ve learned this the hard way by doing that very thing). There are a number of issues, first being that it really harms compile time and module dependencies, bloats the resource files, and also the UI for a given resource may be presented multiple ways, so it’s better to decouple the UI from the backend.
That said, Ash’s DSL is written using Spark, which is a great way to make your own DSL. What I would recommend is writing a Spark DSL for the UI config. The flow would be something like:
- Use introspection to generate the initial DSL
- Use validators (Spark) in the DSL that check against the Ash resources
- Use transformers (Spark) to output a data format the UI components know how to render, or directly generate components (whatever fits your lib’s vision)
