After initialization, `set` disable dates compound together rather than reset and replace

[pencilcheck]

For some reason after setting the disabled times, subsequent changes to disables property would not work and the disabled times will remains the same as when the picker is first initialized.

[amsul]

Can you please replicate this issue and provide a link to it?

From my tests, it’s working just fine. You can disable/enable times like this:

picker.set( 'disable', [ 2 ] ) // Disables the entire 2 a.m. hour
picker.set( 'enable', [ 2 ] ) // Enables the entire 2 a.m. hour
picker.set( 'disable', [ [5,30] ] ) // Disables 5:30 a.m.
picker.set( 'enable', [ [5,30] ] ) // Enables 5:30 a.m.

[pencilcheck]

It's not disable and enable then disable, it's disable after disable.
Like

  picker.set( 'disable', [ 2 ] )
  picker.set( 'disable', [ [5, 30] ] )

expected output should be disabled for 2 a.m. hour, then changed to disables for 5:30 a.m.

[amsul]

Oh I understand now. The disabled times get compounded – not replaced. In order to do what you want, you would have enable each time individually.

[pencilcheck]

Well, is it possible to implement this behavior? It seems more natural this way, as it is "setting" the disable times, not "adding" to it.

[amsul]

Yeah, that’s a good point.. This would be a significant change and so I think I’ll save it until the next major release.

[jrf0110]

I think providing a convenience method for re-enabling everything would be a simple and helpful thing here. At least, it would have solved my problem to just say "re-enable everything, and then set my disabled values". Obviously it's not very hard to implement your own function for that as I did.

[chriswible]

I recently (yesterday) ran into a problem in this area as well - I was able to solve it with what I consider a work around, and I felt there should be an easier way in the api to do it. I'll explain:

I wanted to disable all but a few dates... so on instantiation I would pass in true as the first value for my disabled array, followed by the few dates I wanted enabled. That worked as expected. Then I wanted to change the enabled dates. Not the case anymore.

In the end, I started my calendar with default: [true] so everything was disabled. Then I would explicitly pass in an array of dates to enable. Then, to remove them I would do this (where self.$calendar is a pointer to my picker obj):

  self.$calendar.set('disable', self.$calendar.get('disable')); // disable all currently enabled dates
  self.$calendar.set('enable', dateObjs); // enable the new dates I want (dateObjs is an array of dates, per api spec)

I find the odd thing to be that in order to get the enabled dates I actually call get('disable') but then to enable them, I call enable... which, in turn puts them in the disable array... just feels counter intuitive. No biggie, just a confusion point I had to read the code to figure out.

So, that's my input and also my solution to the problem I had for anyone who runs into the same issue.

[amsul]

@chriswible yeah I agree - the situation is kinda messy at the moment. I’ll try to explain how the two cases work:

1- calendar has a collection of disabled dates

picker.get('enable') // Returns `1`
picker.get('disable') // Returns the collection of disabled dates

2- calendar has all dates disabled except a few

picker.get('enable') // Returns `-1`
picker.get('disable') // Returns the collection of enabled dates

It’s not the most convenient (or rather even appropriate) way to represent this information and I hope to improve this in future iterations. For now I hope at least this explanation clarifies things a bit.

@jrf0110 you are correct - it’s actually quite simple. I’ll be merging in this PR in that regard.

[chriswible]

This explanation is perfect. I agree, not the most appropriate but I understand how it gets. I'd suggest putting a note about this on the api page or something as it's something that takes quite a bit of trial and error to figure out.

Love the picker, though. Easily the most attractive one I've seen. Do you have a list somewhere of the features you intend to implement? I'm not terribly familiar with using git for forks and such but if I end up needing functionality that isn't there I'd rather contribute to your project than keep it to myself.

I know I'm eventually going to need the ability to select a range of dates and multiple, non-consecutive dates... any plans there?

[amsul]

@chriswible note added :)

I do have a few basic items listed in the todo file, but those are not really the long-term goals for this project.

If you are interested in multiple dates selection, I’d suggest checking out Shadow UI. The project is still in it’s early development stages - but the datepicker has a whole bunch of new features that will eventually replace pickadate’s datepicker.