AHBruns
Rethinking phx-no-feedback
Rethinking phx-no-feedback
So, I won’t go into how phx-no-feedback works in detail, but the tl;dr is that it lets you conditionally add a class to an element when it is not showing feedback. In most cases, feedback means validation feedback, aka errors. What this means, is that you effective have to style the feedback version of your component, then you use phx-no-feedback to hide the feedback portions of your component. This works, but I think it can be improved.
I think we should be able to come at the problem from both sides. I propose a new phx-with-feedback class. This would conditionally add a class when feedback is being shown. The idea being that, where it makes sense, we could style the no-feedback state first, then conditionally add classes to that to get to the feedback state’s style. I should mention this is possible today! This tailwind css variant plugin adds support for what I’m describing:
plugin(({ addVariant, e }) =>
addVariant("phx-with-feedback", [
"[phx-feedback-for]:not(.phx-no-feedback)&",
"[phx-feedback-for]:not(.phx-no-feedback) &",
])
)
allows
phx-with-feedback:border-rose-400
I’m simply asking for a slightly better DX around this by creating this variant out of the box. A corollary of this might be that we should deprecate phx-no-feedback in favor of a renamed version phx-without-feedback to keep things intuitive, or alternatively, the new variant could be called phx-feedback to stay inline with the existing phx-no-feedback.
Most Liked
LostKobrakai
While I would generally agree with the results you describe I’m not sure I can agree with the expectation.
Yes core_components are not perfect, but they’re also way more customizable than what we had before 1.7. Nowadays you can at least think about trying to use generators while customizing how the pieces look that the generators generate. That either required very heavy handed css or customizing whole generator templates before. Yes there’s an interface to maintain there, but I’m not sure how else you’d expect generators to call into some customizable functionality. I’d love for that interface to be better documented (statically and across releases) though.
What I find over the top though is the expectation for the generators to be able to build you a complete application. The generators are there to get initial scaffolding done, but not to lift you till v1 of your application. I’d be happy if we eventually get there and someone puts in the work to make that happen, but I find it unreasonable to expect that as the default experience.
I acknowledge that liveview poses a lot of new challenges, but LV is still pre 1.0 and completely optional. If you don’t want to be involved with solving those challenges you’re free to not use LV. If you find the generators to be lacking details there’s also real life example applications with livebeats and todo_trek, which you can look at.
LostKobrakai
I don’t think that’s that’s something the phoenix team should provide – or even could for the matter.
AHBruns
I should add I’m currently working on a component library called Brainz (not yet public), that seeks to fill the role of a core headless UI component library for Phoenix LiveView applications. My plan is to do as I’ve described here, and allow generating a CoreComponents module that uses Brainz components, but only for the use-case of supporting generators, not for generic UI development.
To this end, I might suggest that instead of implicitly importing CoreComponents everywhere, generators should explicitly import CoreComponents as needed (which will hopefully be called something like GeneratorComponents). This would help make it clear those components are not generic.
Popular in Proposals: Ideas
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"