Elixir Blog Post: Plucking the "A" from PETAL

Arrr good stuff. Only a deleted line of JS-code is a good line of JS-code.

This is great and I’ve been thinking about this a lot and recently refactored a lot of the Alpine in Metamorphic (including creating the glide photo effect with JS commands).

Though there’s still a few things that I’m not sure would be as easy to do with JS commands, like counting the number of characters in a form as you type. AFAIK that’s still easier/better experience with Alpine but it’s definitely getting closer!

I tried Alpine I think last year for a few weeks and ripped it out. Tabs can be done via CS and everything is pretty much instantaneous. No JS of any kind is required.

In production, I’m using nested css elements handled by radio buttons.
css

#radio-page-1 { display: none }
#radio-page-2 { display: none }
#radio-page-3 { display: none }
#radio-page-4 { display: none }
#radio-page-5 { display: none }
#radio-page-1:checked ~ &--wrapper >  #display_control > #page-button-1 {border: red 0.2px solid; color: red;}
#radio-page-1:checked ~ &--wrapper > #display_control > #page-button-1:hover {color: white;}
#radio-page-1:checked ~ &--wrapper > &--subgrid1 {display: grid;}
#radio-page-1:checked ~ &--wrapper > &--subgrid2 {display: none;}

html

<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-1" checked value="1">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-2" value="2">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-3" value="3">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-4" value="4">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-5" value="5">
<div id="main--wrapper" class="main-wrapper">
  <div class="main-subgrid1"></div>
  <div class="main-subgrid2"></div>
</div>

Here is another example done using z-index instead:
https://codepen.io/dhs/pen/zYErrW

Modals can also be done via css, but I think Phoenix.JS is a bit cleaner.

Same here. I never understood the appeal of AlpineJS for a LiveView project. When I started using LiveView (long before LiveView.JS) I decided to use JS hooks to keep things simple, cause I didn’t want to add a JS framework. Later on, because everyone was talking about Alpine, I gave it a try out of curiosity. I tried to replace my hooks with AlpineJS. I really had a hard time trying to make it all work, and I came to the conclusion that LV hooks are more flexible and better suited than Alpine for a LiveView project, also because they can hook into LV life-cycle events directly. So I stripped the “A” from PETAL a long time ago. Even more so now that we have LiveView.JS. I suspect Alpine is something so many people were using mainly because so many people were using it.

Yah, glad to know I’m not the only one.

I had so many weird issues with state that I went back to using css with checkboxes/radio buttons to hold the state of the view. Completely separates the state of the client view (in css/html) from the state of the data on the page (js).

That means we need a new acronym to describe our default stack! What should our new, further simplified stack be called?

Maybe we should just start saying LiveView & Tailwind?

Elixir and Phoenix are included in this automatically, and it’s still two words, just like the “PETAL stack”.

Furthermore, once Phoenix v1.8 arrives and starts using TailwindCSS by default, I don’t think calling this stack anything more than just LiveView is very useful…

The acronym PETAL played it’s role before, when we had to compose our own stack on top of LiveView.

Now, as LiveView comes with all the necessary elements built-in (JS commands, TailwindCSS set up by default), I think the PETAL acronym can be retired and we don’t need any replacement for it.

hi there, newbie here – any chance you’d be up for telling us how this approach has played out over the past few months?

Even now I’m holding back till 1.8 comes, we’re still using Phoenix 1.6.x (liveview 0.18 is ok)