Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input values are reset on going back/forward #25

Open
Abduvakilov opened this issue Nov 26, 2018 · 12 comments
Open

Input values are reset on going back/forward #25

Abduvakilov opened this issue Nov 26, 2018 · 12 comments

Comments

@Abduvakilov
Copy link

Abduvakilov commented Nov 26, 2018

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

@adrienpoly
Copy link
Owner

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
Copy link
Author

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
Copy link

caseyprovost commented Aug 21, 2023

@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.
Screenshot 2023-08-21 at 5 01 29 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants