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

Phoenix Forum Questions / Help
1

Hi!

I’m prepping to use flatpickr, a date picking library which attaches to a specific input field. I’m curious as to the best approach to integrate this with Liveview.

I’m using alpine.js to reveal the input field and to create the flatpickr instance on my input field. However, when Liveview handles the validation on change, it seems that flatpickr becomes “detached” from the target - the instance is still in memory, but cannot be opened. In the absence of a way to transfer the existing instance to the updated DOM element, I am assuming my best bet is to track and destroy() existing instance(s) and reinitialize via a client hook called on updated.

This might be exactly the right way to do this, but any other suggestions? My JS knowledge has atrophied a bit and I’m new to Liveview, so I’m just looking for validation that I’m not overlooking something.

Thanks so much for reading!

3 Likes
2

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

3

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.

2 Likes
4

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

1 Like
5

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 %>
1 Like
6

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?

7

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

8

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: “”

6 Likes
9

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-55
Screenshot from 2021-02-25 22-10-55759×479 50.4 KB

10

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

11

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() )
12

Hi @cenotaph - did you manage to solve your problem. I’m struggling to get datepickr to work correctly with LiveView 0.17.

cheers

Dave

13

Nope, I gave up on it and used html5 date picker.

14

Ah that’s a shame - I think I’ll probably do the same.

cheers

15

My man do you know how much heartburn I suffered today trying to fix this god forsaken thing and your solution pulled me from the depths of hades out of the clutches of Mephistopheles himself?

4 Likes
16

This is how I’m using today:

Put this inside the core_components.ex

  attr :id, :string, required: true
  attr :field, Phoenix.HTML.FormField,
    doc: "a form field struct retrieved from the form, for example: @form[:occurred_at]"
  attr :label, :string, default: nil
  def datetime_picker(assigns) do
    ~H"""
    <div id={@id} phx-update="ignore">
      <.input field={@field} phx-hook="DateTimePicker" type="text" label={@label} />
    </div>
    """
  end

Create a new Hook:

import flatpickr from "flatpickr"

/**
 * @type {import("phoenix_live_view").ViewHook}
 */
export const DateTimePicker = {
  mounted() {
    flatpickr(this.el, {
      enableTime: true,
      altFormat: "d/m/Y H:i",
      dateFormat: "Z",
      minuteIncrement: 1,
      time_24hr: true,
      altInput: true,
      static: true,
      wrap: false, 
    })
  },
}

If you are usign TailwindCSS, put this inside you app.css

/**
 * Flatpickr fix full width
 */
.flatpickr-wrapper {
  @apply relative w-full;
}

And use like that

<.datetime_picker
  id="occurred-at"
  field={@form[:occurred_at]}
  label="Occurred at"
/>

This will work fine with :utc_datetime.

8 Likes
17

I wound up going with a very similar solution in a subsequent project, except in my case, I needed to communicate validation errors in my form. I wound up wrapping my phx-update="ignore" with a parent node <dix phx-feedback-for="target" and add some custom CSS to help render validation errors.

1 Like
18

Would you mind showing an example of your error handling on the datepicker field? I’m doing something similar and I’m sort of new the way Elixir handles forms.

1 Like
19

I’m having issues integrating flatpickr using LiveView 1.0. The new way of keeping track of unused inputs doesn’t seem to play nice with how flatpickr is initialized (at least not with the configuration permutations I’ve tried).

The params sent to the LV event handler (using phx-change) don’t contain the _unused_xxx parameter for the date input even if it’s not being touched. This makes the date input immediately seem used. In cases where the date input is validated as required for example, this makes the input show up with its error markup and validation error, even though another input is being edited.

Did anyone notice the same? I’ve tried the wrap option of flatpickr, but also the method of placing the altInput inside phx-ignore element. Without any luck. My hypothesis is that flatpickr “touches” the original input, which confuses the LiveView js runtime that keeps track of the used/unused inputs. But I’m unaware of the internals of this process.