zachdaniel
commented
1 month ago We will be revisiting these design patterns in the next major release. The idea of the prebuilt UI was always to have something quick to get right out of the gate with some specific customizations, and then for users to create their own UIs for it eventually. We thought it would be an early convenience that was discarded relatively quickly, but instead its been a primary sticking point for many users.
Ultimately we're in agreement that the current strategy for UI isn't working. We will leave the current system in place for backwards compatibility. We'll be leveraging igniter to do a mix of code generation and either enhancing the existing reusable components (which do exist) or adding new ones.
jimsynz
I am very greatful to have support for Phoenix with Ash Authentication, and I have some feedback in relation to some of the UI aspects.
I tried an earlier version of this package on another project and ended up "throwing the baby out with the bath water" reeling at the UI approach and reverted to phx.gen.auth given it was easy to understand and reason about with no hidden magic.
After giving this package a second chance on a new project I ended up having to trawl the code trying to work out what overrides existed and how they got applied to what element/elements to work out which overrides I needed to apply and what module I needed to apply the overrides to.
Not the greatest experience And I again had to again say no cigar. Give me Heex templates and a set of well thought out components any day! So hence I did decide to roll my own auth live view forms and it's happy days. I am still using the plug and router aspects of this package.
However it struck me as strange to have so much engineering for the form building and UI overrides approach and then I wondered what the Real-World example Ash app does...
Turns out it too (perhaps tellingly) rolls it's own auth forms, and honestly that was far easier to follow and reason about. It gets most of the value of this package in terms of plugs and routes without using any of the UI from it.
Given that the approach this package uses for building the UI is unlike normal phoenix UI code, I question would it not be time to reconsider the approach used and also at least consider breaking the UI part off into an "Ash Authentication Components" package and fully embrace the component model with attrs and slots instead of using "overrides"?
Perhaps such a component library could even take a 'headless component UI' approach which only considers the accessibility and is silent on the style and visual presentation? (e.g. something similar to Doggo)?
Anyway the intent of my issue is to provide some constructive feedback and my experiences using this package not to criticise the hard work because there is a lot of good stuff here.