I haven’t thought through it too much so maybe there is a good reason things are the way they are, but I sympathize. phx-no-feedback has always read a bit strange to me and I have to keep reminding myself what it means (since I’m not constantly using it).

Update to the above, while this is possible, my example [&:not(:phx-no-feedback)]:border-rose-400 doesn’t actually work as expected. So, please keep that in mind.

I’ve managed make this plugin do the job

    plugin(({ addVariant, e }) =>
      addVariant("phx-with-feedback", [
        "[phx-feedback-for]:not(.phx-no-feedback)&",
        "[phx-feedback-for]:not(.phx-no-feedback) &",
      ])
    )

and I’ve updated the main post to reflect this.

This touches on one the biggest gripes I have with Phoenix.

I am not happy with the core components approach in Phoenix.

To be clear I really do appreciate all the hard work done to make Phoenix what is today, so please take this what follows as constructive feedback and not as some ungrateful complaint.

I do feel there are some rough edges that need to be addressed based on my own frustrations with the framework:

1. I agree handling of feedback variants seems backassward, why not just “phx-feedback” when there is feedback…

2. Lack of class attribute handling to pass down styles to core components.

3. Inability to support light and dark mode without heavy changes. This is where the feedback stuff was a bit strange IMO.

4. The selection of colors in core components means heavy edits which could have been otherwise solved within tailwind configuration using named color palette similar to say daisy ui color concepts.

5. Pulling off a simple alignment of an input with a submit button for a mini form (think email+subscribe button) is not possible without some heavy customisations to support passing down and merging of classes so the form wrappers, input and button are inline.

6. Any changes you make to core_components will get caught up on the next update of Phoenix.

7. The generators expect the contract of core components so you’re stuck with that contract and maintaining compatibility and are likely to run afoul and require refactoring on future changes.

In practice you really do have to AVOID both core_components and liveview generators.

So we are left with the conclusion that core_components and the generators are really just a Phoenix “sales” tool, and not actually intended for real apps that you have to maintain.

The argument may well be that core_components are only there to support the generators. If that is the case then they really should be renamed phx_gen_components because they are not really fit for purpose as core components for a real application as it stands today.

For me the framework is currently a hard fail at the basics of getting a functioning app shell.

Some further observations:

1. When we look around we can’t find a solid functional tailwind UI component suite for Pheonix. And the answer can’t ever be something like petal due to commercial license, kitchen sink, distribution issues and inherent lag keeping up with Phoenix releases.

2. Why is it a kubernetes level dark art to build a simple app shell with a navigation bar, sidebar or breadcrumbs?

3. Do you use a liveview?

4. A nested liveview?

5. Should the navigation liveviews be sticky?

6. Can a sticky view use live_patch?

7. Hmm perhaps a live component in every liveview then?

8. Hmm I wonder if we could instead add a live component to a layout?

9. Sigh.. where does it get the current/active uri from?

10. Perhaps a plug, no … dig dig dig perhaps a live session on mount hook ?

11. Close but no… more digging, perhaps I also need a handle params hook?

12. Having “fun” with Phoenix…

It gets very deep very quickly without any obvious well worn path for a basic app shell.

Yes it’s all doable given enough determination but there is a ton of frustration/developer-unfriendliness to actually get the basic shell of a typical SAAS application working and it really shouldn’t be this hard.

My point is that .Core Components needs a HEAVY RETHINK to actually be useful for real applications.

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.

I don’t really care about the generators, per-se, as they are of limited value.

I care about a solid set of real core components you can actually base an app on. It’s too limited for that currently being a stop gap for generators.

Currently we get neither a good core component solution or generator solution in practice.

Ideally a solid core UI component set should enable a path to more powerful UI generators to follow however, but we desperately need the UI components first.

I don’t think that’s that’s something the phoenix team should provide – or even could for the matter.

Yes I have looked at these because there is NOTHING in the guides that explain how to achieve outcomes, for basic app shell needs, not even a strategy to solving navigation. It’s a lot of guesswork currently.

Well the framework will probably remain fringe if it doesn’t lead to productivity.

I’ve used many frameworks and it’s a long way from being productive. In almost every other framework these are solved problems, in Phoenix liveview its a mystery.

So the core components should be called, throwaway_components or sample_components, it’s hardly appropriate and somewhat misleading to be called “core” components when they aren’t.

It’s actually forced me to rethink app strategy because the gap is so wide. I can’t be alone in my assessment.

It’s less likely that phoenix or liveview will be in that future and I will instead use elixir for backend only and develop frontend in established JS frameworks which provide productivity and better UI experience for less pain.

Fair enough. I think we will eventually get there, but I don’t think it’ll be the phoenix core team providing that, but rather an external project building on top. And likely after LV 1.0.

However my experience is the opposite. I’ve yet to find a UI scaffolding project, which doesn’t suck one way or another. Usually they’re great for as long as you do exactly what they expect, but easily become a major pain if you don’t.

I agree that UI scoffolding is never ideal, but there should be some patterns and guides for solving the common needs of 90% of apps.

Currently the “discovery” is killing the project and I have developers using Svelte already past where got with liveview in a few houra. So we ditch the liveview, the phoenix and go API only with JS.

Frameworks have to deliver value vs the alternative and it’s not there yet.