Closed knitevision1 closed 6 years ago
Looks like you're only showing it relatively to some element, but actual position in DOM doesn't change form that.
What is the reason that you can't instantiate PickMeUp on attach_to
initially? Would be useful to know more about your use case.
@nazar-pc Well I just needed a quick and reliable way to show the calendar in another place, rather than close to the element that triggers it's appearance.
Using CSS class - not good enough.
Attach a datepicker and then use .show / .hide
methods on event - too.
So I came up with this. Yes, position in the DOM doesn't change (didn't mean to do that), but an element, relative to which the calendar is rendered, changes, which can be helpful in some cases.
So, this is purely presentational, UI/UX feature.
Maybe setting option should be renamed to relative_to
What is the reason that you can't instantiate PickMeUp on
attach_to
initially?
Because it will require additional setup to pass values to the input/form to post
them, if attach_to
is a <div>
I'd rather like to see something generic responsible for positioning. I mean, so that you can replace default positioning algorithm with your own (because built-in is pretty simple). It was actually already requested in #111. In your case, however, I'd better use events handlers to combine datepicker in one place and input in another place (in this case you'll be able to use upstream version and upgrade to newer releases).
So it would be nice if you can implement something more generic (I imaging position
event) for this use case, rather than in a way it is currently. There are too many edge cases, I can't support all of them.
I've just published 3.1.0 that supports custom function in position
option, so now it is possible to implement arbitrary positioning in generic way and this PR is not needed
Not sure who will ever need this functionality, well, I needed for some reason. This allows to show/hide more smoothly and numerous places to hang the plugin on the page.