Correct strategy for using datepicker attached to an input field with Liveview?

Hi @rio517

I’m just curious as I’m about to integrate a datepicker into my application. Is this an issue with flatpickr itself. Have you tried other datepickers and do you get the same issues?

cheers

Dave

That would probably apply to any datepicking library.

I re-read the docs and missed the fact that one could attach phx-update="ignore" to disable patching on specific DOM nodes. I added this to my input field’s parent and wallah! This obviates the need to manage specific instances.

Of course, if anyone has any better ideas, let me know!

That said, I’m surprised that Liveview patches the entire form when validating. I would have thought Liveview would focus on what was changed, not the entire form. I’m guessing that since Liveview patches elements based on changed assigns, that the round trip of the form_data is the change that causes the DOM patch.. ?? I’m hoping I can find some time to look into that more and maybe open a github issue to gather more info.

Great to know about the phx-update=“ignore”. Also I think you are right about the round trip for form data as the entire form is passed back and forth even when validating a single field.

I’m going to be a bit cheeky and ask if you are able to provide your implementation of flatpickr with live-view?

cheers

Dave

I’m not sure if this is a shining example of how to do things - as mentioned I still wonder if there are easier ways. Here is a simplified example of where I am ending up - but note that I’m still in the middle of building a multi-step form using Alpine.

// js bits

let liveSocket = new LiveSocket("/live", Socket, {
  params: {_csrf_token: csrfToken},
  dom: { // for alpine.js
    onBeforeElUpdated(from, to){
      if(from.__x){ window.Alpine.clone(from.__x, to) }
    }
  }
})

window.skillFrequency = function () {
  return {
    flatpickrInstance: null,
    setUpFlatpicker(frequency){
      this.flatpickrInstance?.destroy();
      this.flatpickrInstance = setupFlatpickr.build(frequency);
    }
  }
}

window.setupFlatpickr = {
  settings: {
    one_time: {
      fieldWrapperClass: ".flatpickr-onedatetime",
      options: {static: true, minDate: "today"  }
    }
  },
  build (targetFrequency) {
    if (targetFrequency in this.settings) {
      var targetSettings = this.settings[targetFrequency]

      var options = {
        ...targetSettings.options,
        ...{appendTo: document.querySelector(targetSettings.fieldWrapperClass)}
      }
      return flatpickr(targetSettings.fieldWrapperClass + " input", options)
    }
  }
}

// the form…

<%= if connected?(@socket) do %>
  <%= f = form_for @changeset, "#", id: "subskill-form", phx_change: "validate", phx_submit: "save", "x-data": "skillFrequency()"  %>
    <div class="field flatpickr-onedatetime">
      <%= label @form, :one_time_at %>
      <div class="control" phx-update="ignore">
        <%= text_input @form, :one_time_at, class: "input", placeholder: "Select Date" %>
      </div>
      <%= error_tag @form, :one_time_at %>
    </div>
  </form>
<% end %>

Duck question, when you look at the debug log, is it patching the whole form or the whole view? maybe something else is triggering the full patch?

Thanks @rio517 - I’ll study the code as it is certainly something I need to do. cheers.

I’m currently doing it in an input_helper based off of https://dashbit.co/blog/dynamic-forms-with-phoenix:

  defp input(:datetime_select, form, field, opts) do
    date = if Map.has_key?(form.data, field) && !is_nil(Map.get(form.data, field)), do: NaiveDateTime.to_iso8601(Map.get(form.data, field)), else: ""
    content_tag :div, class: "control", phx_update: "ignore" do
      apply(Phoenix.HTML.Form, :text_input, [form, field, [class: "input #{state_class(form, field)}", phx_hook: "datetimeHook", value: date] ++ opts])
    end
  end

import flatpickr from "flatpickr";

export const datetimeHook = { 
  mounted() {
    flatpickr(this.el, {
      altInput: true,
      altFormat: "Y-m-d h:i K",
      dateFormat: "Z",
      enableTime: true,
      parseDate(dateString, format) {
        var wrongDate = new Date(dateString);
        var localizedDate = new Date(wrongDate.getTime() - wrongDate.getTimezoneOffset() * 60000);
        return localizedDate;
      },
    });
  }
}

Saving it as :utc_datetime.

I call it like:
<%= input f, :published_at, field_modifier: "", label: "Publish Date" %>

Though I forget why I have field_modifier: “”

It is patching the whole form. This even occurs in a newly generated app on :phoenix, "1.5.8", with nothing else in it.

> mix phx.new shiney --live
> cd shiney
> mix ecto.create
> mix phx.gen.live Publication Author authors name:string color:string count:integer
> mix ecto.migrate
> mix phx.server

Screenshot:

Screenshot from 2021-02-25 22-10-55759×479 50.4 KB

I wounder if because the @changeset changes, the f = form_for .. changes, so all the builder’d elements change too?

I have hit the same problem with bulma calendar.

no matter what I do phoenix destroys the calendar when I open a modal or add new object.

I can’t add them without the phx-update=ignore

I can re-add them with this listener but then I will get multiple instances on it.

I am going to investigate jsOps when I have more time

window.addEventListener("phx:page-loading-stop", info => doStuff() )