Phoenix 1.7.1 without TailWind CSS

Phoenix Forum Questions / Help
,
1

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 :slight_smile:

2

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.ex with 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.

1 Like
3

I think @LostKobrakai wrote a Bulma compatible core_component.ex.

But I am not sure if it is publicly available :slight_smile:

4

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.

1 Like