Input values are reset on going back/forward

[Abduvakilov]

The input values of flatpickr are reset to default value on first going back and on second return removed.
I have observed the issue on Safari, app with turbolinks and flatpickr with altInput.

Expected behaviour

flatpickr should keep last typed value on returning back
P.S. I haven't tested the issue on other environment yet

[adrienpoly]

Thanks for reporting this issue.
I was able to reproduce it in this little repo
https://glitch.com/edit/#!/dull-basil?path=src/controllers/datepicker_controller.js:1:1

I would need to go back into the Turbolinks Lifecycle and cache handling to properly understand what is going on. For now, as a fix I was able to get it to work by like this:

import Flatpickr from "stimulus-flatpickr";

export default class extends Flatpickr {
  
  change(selectedDates, dateStr) {
    this.data.set('defaultDate', dateStr)
  }
}

at every date change, I update the default date data-attribute. Therefore when Turbolinks cache the page before going to the next, it caches the default date attribute too. When coming back this default attribute is picked up by stimulus-flatpickrin the connect function automatically.

I will need more test to see if I have to make it a default behavior or not of the wrapper.

Let me know if this workaround is working too on your side

[adrienpoly]

actually, I made a few more tests and it looks like it works only for the second time, not the first time...
Will dig into this a bit later

[adrienpoly]

For it to work from the start, I had to use defer instead of async when loading my js bundles:

<script src="bundle.js" data-turbolinks-track="reload" defer></script>

and keep updating the data-attribute onChange

change(selectedDates, dateStr) {
    this.data.set('defaultDate', dateStr)
  }

Here is a working demo

https://glitch.com/edit/#!/dull-basil?path=src/controllers/datepicker_controller.js:5:2

[Abduvakilov]

Thanks for your answer. I have further tested with altInput false, but issue persisted.
Your suggestion has pastially fixed the problem. Because i used value attribute instead of data-flatpickr-default-date, the value was resetting first to value attribute and on second it was removed. Should I always replace value with defaultDate?

[adrienpoly]

can you try to send me an example to reproduce exactly what you are doing and the issue
you can use this example as a starting point
https://glitch.com/edit/#!/dull-basil?path=src/controllers/datepicker_controller.js:5:2

Thanks

[Abduvakilov]

Sorry, I typed previous message in a hurry on mobile. Your suggestion fixed my issue partially, because I use value attribute not defaultDate the date gets erased on returning back if not changed
You can test it here https://glitch.com/edit/#!/pale-coast?path=public/index.html:13:13
So i had to additionally write this kind of ugly solution, but it seems to fix the issue

	initialize() {
                ...
		let value = this.element.value || this.element.querySelector('input').value;
		if(!this.data.has('defaultDate') && value)
			this.data.set('defaultDate', value);
	}

You can test it here https://glitch.com/edit/#!/heartbreaking-dust?path=src/controllers/datepicker_controller.js:6:4

[Abduvakilov]

The second example isn't working, but i have it working on my local environment.
this.element.querySelector('input').value is needed for wrapped option

[Abduvakilov]

I have recreated small part of the wrapper and the issue came after the line

  disconnect() {
    this.fp.destroy()
  }

https://glitch.com/edit/#!/probable-suede?path=src/controllers/datepicker_controller.js:11:21

Maybe we should save the value before destroy?

[Abduvakilov]

possibly the reason
https://github.com/flatpickr/flatpickr/blob/d4b3feb232cbb1cc935ee24b3a3a44b7e2122fa7/src/index.ts#L1289

[adrienpoly]

Thanks for investigating this issue further.
As you said it comes from Flatpikr clearing the input value on disconnect (destroy).
Turbolinks cache happens after disconnect so when clicking back button Turbolinks restores the cached page but with no value.
A hacky way to solve this is to overwrite the disconnect function like this.

disconnect() {
    const value = this.element.value
    this.fp.destroy()
    this.element.value = value
} 

live working example:
https://glitch.com/edit/#!/witty-alibi?path=src/controllers/datepicker_controller.js:14:3

I need to release a new version soon 1.1. I will add this patch to the official wrapper. This is something very linked to Turbolinks behavior. I am not sure Flatpickr would change this behavior whereas this wrapper is really made to work well with Turbolinks

Will close this issue with the associated PR and release for the fix

Once again thanks for pointing it out

[Abduvakilov]

Thank you for the good work. But you should probably use this.fp.input instead of this.element, because there is wrap option. Flatpickr also uses self.input

[caseyprovost]

@adrienpoly I still see this issue in 3. I can reproduce 100% of the time by first doing pagination on a list (which uses turbo frames) and then click the back button.

-- EDIT --

Some clarifying points:

• We have a search box on top of the list. The list has pagination and is in a Turbo frame; the search boxes are outside of it.
• Instead of values clearing, we see inputs duplicated, which is viewable in the attached screenshot. The 2 inputs immediately to the left of the button are the real/good ones.

[gap777]

We're seeing very similar experiences as @caseyprovost.

Filter panel on left, paginated table (in turbo frame) on right.

Filter panel uses flatpickr for date filter. Hitting browser "back" causes 2nd flatpickr to appear.

• fetching "next" page of results via link in turbo frame; flatpickr stimulus controller is neither disconnected nor re-connected.
• hitting "back" button in browser correctly updates table and URL
• hitting "back" button cycles through flatpickr stimulus lifecycle: disconnect, initialize, connect
• hitting "back" button produces second (additional) flatpickr generated HTML as a sibling of the first (preceding) HTML snippet