Conversation
|
I'm opening up this PR to get some early feedback. If this approach is supported I can update the tests and make any requested improvements. |
ljharb
left a comment
There was a problem hiding this comment.
Overall I very much like the approach.
f9a5f5f to
d8d181b
Compare
|
@ljharb I rebased off master and attempted to fix some of your suggestions. Let me know what you think. |
|
@ljharb any other comments? Otherwise I'm going to add some tests. |
ca4a983 to
304df78
Compare
|
@ljharb I wrote a few tests but definitely could use some feedback. Seems like the tests really get into the implementation details so I could def use some feedback. |
single to double quotes and indentation Co-Authored-By: ianduvall <ianduvall@users.noreply.github.com>
304df78 to
3d661a2
Compare
|
Any updates on this?? |
|
I'm going to close this. This doesn't seem like the best approach. In the meantime, I'm just going to remove my date picker from the DOM and then immediately add it again so that |
|
@ianduvall why do you no longer think this is the best approach? |
|
The components were designed for the visible month to be controlled by the component so that it can manage animations, etc. This PR breaks that and tries to give the user control of the visible month but it creates this half user managed, half component managed approach. I think an ideal solution would treat the visible month as a user input that gets passed in like the dates and then the component would handle changing from the old visible month to the new visible month. For example, the component could animate the calendar sliding to the new visible month. But this would require a more extensive PR and a paradigm shift in how the visible month is managed. |
|
@ianduvall How did you manage to rerender your component completely in order to set the visible month as wanted ? PS : too bad this PR is not finally merged ... |
|
@jchapelle you can try setting the Not pretty as, in my case, there's a frame glitch... but does the job |
|
Exacty what I did. It is not very pretty. As you mentioned, there is a
blink effect as a side effect but it works ...
…On Fri, Apr 12, 2019 at 11:13 PM Pedro Abreu ***@***.***> wrote:
@jchapelle <https://github.com/jchapelle> you can try setting the key
with a date value, say the value of the input. A change in key will force a
re-mount of the component so the initialVisibleMonth will kick in with
the new value.
Not pretty as, in my case, there's a frame glitch... but does the job
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1487 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF4GXXF38gpICvC45lP6K7UvfdNISkNEks5vgPbrgaJpZM4ZNvct>
.
--
Jean Chapelle
|
This PR adds the prop
visibleMonthto the componentsDayPicker,DayPickerRangeController, andDayPickerSingleDateController. This provides the consumer the option to control the visible month of these components.This is an alternative to #1481 which attempts to solve #1320. The major difference is this PR adds the flexibility for the consumer to jump to any arbitrary month. This also would be backwards compatible with the prop
initialVisibleMonthsince the new propvisibleMonthis an opt-in override.TODO