Ohhhhhhhh I misunderstood, sorry 'bout that 
I always get emailed about Elixir releases but I forgot how I even did that 
sodapopcan
groig
BrightEyesDavid
I think you can get emails from Discourse here. E.g., the Phoenix News section:
See the alarm bell, top-right. I use ‘Watching first post’.
groig
Just did it. Thank you. I see there are posts for other 1.X final releases just not 1.8.0 yet, I apologize for the impatience
sodapopcan
Ah right, I joined the elixir-lang-ann google group mailing list. Of course I’m on this forum every day so I always see the update anyway, but the email arrives like 10 mins earlier or something
AndyL
tomkonidas
Schultzer
The pain is real, again this is why vanilla CSS and JS still are the kings, as it is portable and performant.
Eiji
Honestly if I would maintain the CSS part I would include dart_sass dependency as default. Since Phoenix (except core_components.ex) only have generic styles for generators I would move them to their own classes like myapp-hero and use @include … to add Tailwind styles:
// phoenix_tailwind.scss
@mixin hero {
// use @extend for each Tailwind class from Phoenix choice
@extend .hero-tailwind-class1, hero-tailwind-class2, .hero-tailwind-class3;
}
// phoenix.scss
@use "phoenix_tailwind";
// low specificity - easy to customise
// uses "myapp-" as a prefix
// to not conflict with other libraries/frameworks like .btn in bootstrap
:where(.myapp-hero) {
@include phoenix_tailwind.hero;
}
// app.scss
@use "phoenix"
Such solution is:
- Easy to upgrade - no conflicts with classes
- Easy to generate - no
Tailwindclasses when--no-tailwindoption is used - Easy to customise - people can create
phoenix_bootstrapreally easily without even touching templates - Easy to modify - no need change each newly generated page
The only “problem” would be with core_components.ex file as it’s not layout or generic page, but is it really a big deal to add some kind of scss attribute that would be used by @before_compile to generate a core_components.scss?
Then when --no-assets is used all we need to do is to add a simply if to the generators for each scss macro call …
attr :level, :integer, default: 1
slot :inner_block, required: true
# simple if condition in generators goes here …
# classes for the main element
@scss ~w"header-class1 header-class2 header-class3"
# classes for the element with a -group class suffix
@scss "-group": ~w"hgroup-class1 hgroup-class2 hgroup-class3"
# classes for the element with a -heading class suffix
@scss "-heading": ~w"heading-class1 heading-class2 heading-class3"
# custom def drops + fetch `@scss` and prepares it for `@before_compile`
# app = Mix.Project.get([:app])
# or:
# @use_opts[:otp_app]
# func_name = :header
# accumulate:
# @component_classes {"#{app}-#{func_name}#{suffix}", […]}
# finally @before_compile uses `__ENV__.file` to generate: assets/scss/core_components.scss
def header(assigns) do
~H"""
<header class="myapp-header">
<hgroup class="myapp-header-group">
<.dynamic_tag tag_name={"h#{@level}"} class="myapp-header-heading">
{render_slot(@inner_block)}
</.dynamic_tag>
</hgroup>
</header>
"""
end
With this we keep classes in core_components while having consistent scss assets directory and therefore have all good stuff coming from it mentioned above.
Schultzer
I don’t see why the default couldn’t be vanilla, and then have command arguments or igniter commands to add tailwind and etc.
Although I don’t think this is going to happen, I’m just here to preach to the younger people the same way a older and more experienced developer did for me when I started.