Option to pass a --no-daisy flag when creating a new phoenix project

Chat & Discussions Proposals: Ideas
,
61

I’ve contributed to the templates before. They are EEx text templates that generate Elixir files.

If anyone would implement a --no-daisyui flag for mix phx.new, that means one of:

  1. With the flag, the daisyui Integration code and classes are not generated, and the initial app looks “broken”. Or,
  2. One needs to reimplement in pure Tailwind a minimal alternative to the daisyUI classes.

In either case, there’s also all the other mix phx.gen.* generators, which perhaps one might also ask for a --no-daisyui version.

Have a look at the repo. I personally think the added complexity to the templates is not worth pursuing.

3 Likes
62

Yeah that sounds like more hassle than it’s worth probably. I’ll check it out though. Thanks for the info!

63

Yeah, it sucks because if we just followed semantic styling we wouldn’t have such a tight couple framework, it would be easier to maintain.

It properly be another five years before everyone is looking at this and asking themself what the heck we’re all thinking back then.

1 Like
64

Most people can’t be bothered to learn and use maintainable CSS. Slapping some classes and brute-forcing a combination until it looks acceptable is good enough, I guess. CSS is so powerful nowadays and styles can be actually much simpler than before.

1 Like
65

I mean, DaisyUI is pretty semantic? It’s certainly not Tailwind soup.

1 Like
66

I think José put it very well:

Until someone will actually do the work and show an alternative, show with code an undeniable better way to implement the code generators (new project and adding to existing project), with a clear path forward to land it in Phoenix 1.9, 1.10, or 2.0, indeed things are not going to change with just arguments and opinions.

Other than the existing generators, I’m aware of the work on Igniter ( igniter | Hex ), though I haven’t used it in earnest. I think Igniter follows the “additive” pattern suggested in Option to pass a --no-daisy flag when creating a new phoenix project - #55 by Schultzer . How suitable it would be to replace the existing generators I don’t know. As per docs, it can build on top of phx.new! Home — igniter v0.7.2

And the Phoenix team is aware of Igniter too, see Augment Tailwind with Daisy UI · Issue #6121 · phoenixframework/phoenix · GitHub.

So I gave a link to the existing templates earlier. Another pointer I can offer is suggesting looking at Igniter and perhaps using it to add an alternative assets stack to a project started with --no-assets, as that would give a blank canvas to do JS and CSS as one thinks is best.

1 Like
67

That’s the path I took with phoenix_vite, although I simply delete files of the default boilerplate rather than building on --no-assets. Generally I think many people would enjoy a igniter based rebuild of the generators, but as mentioned it also needs someone to take on the work and at least some initial maintenance.

As for the core components. I wouldn’t necessarily agree that they never useful long term, but I also wouldn’t agree that they’re always useful long term. Especially the form components lack quite a bunch of composability of quite common components of forms. There was an interesting talk of Adam Wathan at laracon, where the first section is all about such affordances. One doesn’t need to agree with the way he solved things using tailwind to agree that not all inputs look the same and composability needs to be at more granular levels.

I’m not sure how much appetite there is to improve core components on that metric and I also think it needs someone experienced in this kind of work to make useful judgement calls of what’s a good or bad change. I also do not feel like phoenix needs to go to that length given in the end components are likely to evolve to more purpose built ones matching a given project more so than being generally usable.

3 Likes