A conversation around Liveview about its design patterns

My 2C on modals:

They are an easy solution for web design, but usually the wrong one. I can see why the phoenix team leans on them for the auto generated pages, since there are less layout considerations with them. I have been slowly moving most of the modal forms out of my app into separate pages, which isn’t that hard IMO, but requires a bit more thought on how to integrate them nicely.

I think the default generated pages could be improved by only using modals for index pages, and using a different design for forms on show pages, but honestly I think it’s fine as-is since it’s easy to refactor.

1 Like

I personally think that the scaffolding tool should not be treated as strictly a learning tool. I would rather it be used as a simple starting point vs having everything and the kitchen sink to start with.

I understand why the modals are in the scaffolding generators. It’s mostly to showcase how they embed a LiveComponent (the form) into another (the resource in question) It also showcases live navigation and send_update. But sadly IMO these learning examples are not great use cases for these features since you would not normally want to use a modal in these ways in most cases. This is more to my point, we are pushing bad UX design for the sake of showing off a feature. I think this is over all harmful because a spike never makes it to production… :joy: :sob:


Chris McCord has a repo you might find interesting where he demos all the dynamic form strategies: GitHub - chrismccord/todo_trek

And an option on abstraction of authentication into scopes.