Gilou06
Phoenix 1.7.1 without TailWind CSS
Hi,
I’m seeking CSS help for transition of a project from Phoenix 1.6.6 + Live View 0.18.3 + Surface 0.8 + Bulma to Phoenix 1.7.1 + Live View 0.18.16 + Surface 0.9.4
I have successfully adapted the code related to verified routes, but I struggle with the transition to Tailwind CSS, specifically on the flash notices : it stays always on on non LiveView pages and flashes at every page reload on LiveView pages. It makes sense since flash and flash-group defined in core components uses TailWind and I don’t.
I’d like to avoid ditching Bulma since I’m deep into it now, and still have flash and modals working.
In other words, can someone point to me what I should do to have flash work again with Phoenix 1.7.1 without switching to TailWind ? Should I rewrite flash function in core_components ?
I hope I described my issue in a clear way.
Thanks for your help
Cheers
Jean-yves ![]()
Marked As Solved
c4710n
Yes.
A quote from Phoenix 1.7.0 released: Built-in Tailwind, Verified Routes, LiveView Streams, and what’s next:
First, you can customize your core UI components to suit whatever needs, designs, and tastes that you have. If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in
core_components.exwith your framework/UI specific implementations and the generators continue to provide a great starting point for new features whether you’re a beginner, or seasoned expert building bespoke product features.
So, that’s recommended way.
Also Liked
aiwaiwa
I don’t have an immediate answer to the why flash reappear - it also bothers me, all I did so far is moving flash a bit up by z axis so it’s not obstructed by the modals.
Regarding, Tailwind in core_components. The easiest way to remove the class soup and move away from Tailwind (in case one wants to) would be role classes, right?
So, let’s say I rewrite the <.back /> component with something containing classes for each element, to make it look more like a “regular” CSS (sorry there’s no -- dashes in names) and potentially easier to switch to another CSS / SASS library:
def back(assigns) do
~H"""
<div class="core-back-wrap">
<.link navigate={@navigate} class="core-back-link">
<.icon name="hero-arrow-left-solid" class="core-back-icon" />
<%= render_slot(@inner_block) %>
</.link>
</div>
"""
end
/* <.back /> */
@layer components {
.core-back-wrap {
@apply mt-16;
}
.core-back-link {
@apply text-sm font-semibold leading-6 text-zinc-900 hover:text-zinc-700;
}
.core-back-icon {
@apply w-3 h-3;
}
}
This approach would first of all help with styling at one place, switch to other libraries easily, potentially group up repetitions, provided I’m good at naming conventions.
The good trade-off is, of course, is that I’m not afraid to edit CSS as much as core_components.ex which I feel should be left intact - from even upgrading purposes, as I have to always maintain all my fixes between the Phoenix updates - not the most hard job, but definitely makes you a little nervous.
Edit: Also, obviously, those core- classes could be reused with @apply core-back-link; for any subsequent styles. This restores some of the CSS inheritance, while not turning it into unmanageable layering.
Popular in Questions
Other popular topics
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
- #api
- #forms
- #metaprogramming
- #security
- #hex









