Hotwiring Modals

In my previous post I ended on kind of an "up key" with job done – which with hindsight probably was a bit exaggerated. I never got to mention Caleb Porzio who created AlpineJS.

app/views/accounts/_modal.html.haml is not ripe for generalization yet but this is what it looks like:


:coffeescript

  window.modalData = () ->
    {
      modalOpen: false,
      dispatcher: null,
      toggleModal: () ->
        @modalOpen = ! @modalOpen 
      initModal: (w,d) ->
        @dispatcher = d
        document.body.classList.add 'overflow-hidden'
        w 'modalOpen', (value) =>
          if (value == true)
            document.body.classList.add 'overflow-hidden'
          else
            document.body.classList.remove 'overflow-hidden'
      sendModal: () ->
        @modalOpen = ! @modalOpen
      openModal: (e) ->
        @dispatcher 'opened-event-modal',''
        @toggleModal()
        if e.detail!=''
          el = document.getElementById('account_modal_form')
          el.innerHTML = e.detail
          el.style.zIndex = '99'
      closeModal: () ->
        @dispatcher 'closed-event-modal',''
        @modalOpen = ! @modalOpen
    }

.fixed.inset-0.z-10.grid.place-content-center.justify-items-center{ :"x-data"=>"modalData()", :"x-init"=>"initModal($watch,$dispatch)", :"x-show"=>"modalOpen", :"@open-event-modal.window"=>"openModal", :"@close-event-modal.window"=>"closeModal()" }
  .absolute.inset-0.bg-black.opacity-10
  / %span.hidden.sm:inline-block.sm:align-middle.sm:h-screen( aria-hidden="true") ​
  #account_modal_form
    = render partial: "form", locals: { account: @account, header: t('.konto') }

The first (real) line of HTML beginning with .fixed.inset-0 holds these constructs:

:"x-data"=>"modalData()" – which scopes the reach of variables and methods to this DOM element and children

:"x-init"=>"initModal($watch,$dispatch)" – initializes scoped variables and if you need access to stuff like a dispatcher from your JS this is the proper place to announce it  

:"x-show"=>"modalOpen" – will show/hide this DOM element depending upon the truthiness of modalOpen

:"@open-event-modal.window"=>"openModal" – this is how eventListeners look like using AlpineJS.

:"@close-event-modal.window"=>"closeModal()" – label the event and attach .window and define what should happen.


With the modal sitting duck we just need a ways to call it up. I believe to have left off just about setting the rows right in my previous post, but I had to refactor that part (more will come, I anticipate):

.table-row.bg-white{"x-description" => "Odd row", id:  dom_id(account) }
  .table-cell.px-6.py-4.whitespace-nowrap.text-sm.cursor-pointer.font-medium.text-gray-900{ :"@click" => "openModal('#{edit_account_path(account)}')"}
    = account.name
  .hidden.lg:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    /= #link_to account.participant.name, 
  .hidden.md:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    = account.service_plan
  .hidden.sm:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    \-
  .table-cell.px-6.py-4.whitespace-nowrap.text-right.text-sm.font-medium
    = link_to 'Destroy', account, method: :delete, data: { confirm: 'Are you sure?' }

There's at least one more post after this one – this pattern begs a kind of componentization and my first target will be ViewComponents possibly married to Stimulus.

First, however, we will continue finishing the naive implementation with alpineJS, Turbo, and Hotwire. Check out the previous post if you'd like to see how I managed to get the 'new account'  working with a modal.

In the above code-block .table-cell.px-6.py-4.whitespace-nowrap.text-sm.cursor-pointer.font-medium.text-gray-900{ :"@click" => "openModal('#{edit_account_path(account)}')"} is about the only really interesting thing. It tells AlpineJs to go look for a method called openModal when the user clicks somewhere on the row.

I've put that – and a couple others – in the top of the view:


  :coffeescript 

    window.indexState = () ->
      {
        dispatcher: null,
        initModal: (d) ->
          @dispatcher = d
        openModal: (url) ->
          d = @dispatcher
          if url!=''
            fetch url
              .then (response) ->
                response.text()
              .then (response) ->
                d 'open-event-modal', response
        editModal: (id) -> 
          @dispatcher 'open-event-modal', id
        closeModal: () ->
          @dispatcher 'close-event-modal',''
      }

I woun't hold it against you if this is confusing! I'll admit to not labelling the methods to afford easy access but once you understand the scoping of AlpineJS I at least find it quite sensible to label methods alike – they will work in unison to get the job done after all.

There's one more 'openModal' in the section header affording the 'Ny konto' (new account)


:coffeescript

  window.sectionData = () ->
    {
      dispatcher: null,
      init: (d) ->
        @dispatcher = d
      openModal: () ->
        d = @dispatcher
        fetch '/accounts/new'
          .then (response) ->
            response.text()
          .then (response) ->
            d 'open-event-modal', response
      closeModal: () ->
        @dispatcher 'closed-event-modal',''
    }


.bg-white{ :"x-data" => "sectionData()", :"x-init" => "init($dispatch)"}
  .px-4.py-12.max-w-7xl.mx-auto.sm:px-6.lg:px-8
    .pb-5.border-b.border-gray-200.sm:flex.sm:items-center.sm:justify-between
      %h1.text-2xl.font-semibold.font-display.text-gray-900.sm:text-3xl.ml-5
        = section_title
      .mt-3.sm:mt-0.sm:ml-4
        %label.sr-only{:for => "search_candidate"}= section_search
        .flex.rounded-md.shadow-sm
          .relative.flex-grow.focus-within:z-10
            .absolute.inset-y-0.left-0.pl-3.flex.items-center.pointer-events-none
              %svg.h-5.w-5.text-gray-400{"aria-hidden" => "true", :fill => "currentColor", :viewbox => "0 0 20 20", "x-description" => "Heroicon name: solid/search", :xmlns => "http://www.w3.org/2000/svg"}
                %path{"clip-rule" => "evenodd", :d => "M8 4a4 4 0 100 8 4 4 0 000-8zM2 8a6 6 0 1110.89 3.476l4.817 4.817a1 1 0 01-1.414 1.414l-4.816-4.816A6 6 0 012 8z", "fill-rule" => "evenodd"}
            %input#search_candidate.focus:ring-indigo-500.focus:border-indigo-500.w-full.rounded-none.rounded-l-md.pl-10.sm:block.sm:text-sm.border-gray-300{:name => "search_candidate", :placeholder => section_search, :type => "text"}/
          %button.-ml-px.relative.inline-flex.items-center.px-4.py-2.border.border-green-300.text-sm.font-medium.rounded-r-md.text-green-800.bg-green-400.hover:bg-green-200.focus:outline-none.focus:ring-1.focus:ring-green-500.focus:border-green-500{ type: "button", :"@click" => add_new_logic }
            = add_new_btn_title

You may notice how I've started "componentizing" the section_header using variables to labels and methods like section_title and add_new_logic – we'll revisit this in another post most certainly.

This partial gets called from the `/app/views/accounts/index.html.haml` like

= render partial: "shared/section_heading", locals: { section_title: t('.title'), section_search: t('.search'), add_new_logic: "openModal()", add_new_btn_title: t('.new') }

All there is left is to adjust the controller. I've moved the renders into templates

  # POST /accounts or /accounts.json
  def create
    @participant_type = params[:account].delete :participant_type
    @account = Account.new(account_params)
    respond_to do |format|
      if @account.save
        @account.set_participant @participant_type 
        format.turbo_stream 
        format.html { redirect_to accounts_url, notice: "Account was successfully created." }
        format.json { render :show, status: :created, location: @account }
      else
        format.turbo_stream 
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end

  # PATCH/PUT /accounts/1 or /accounts/1.json
  def update
    respond_to do |format|
      if @account.update(account_params)
        format.turbo_stream
        format.html { redirect_to accounts_url, notice: "Account was successfully updated." }
        format.json { render :show, status: :ok, location: @account }
      else
        format.turbo_stream
        format.html { render :edit, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end

The /app/views/accounts/create.turbo_stream.haml will act on the result of the save

- if @account.errors.any?
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: @account, header: t('.konto') }
- else
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: Account.new, header: t('.konto') }

whereas the /app/views/accounts/update.turbo_stream.haml will do - well almost verbatim the same?!?

- if @account.errors.any?
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: @account, header: t('.konto') }
- else
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: Account.new, header: t('.konto') }
  = turbo_stream.replace( @account )

I'm positively sure this does not even make it to the first beta – for one because it does not really take advantage of the Turbo(stream); it's little more than a bunch of JavaScript incantations not qualifying for much 'turbo' :)

We'll see –