[Roadmap] vanilla-calendar-pro v3.0.0

[uvarov-frontend]

This issue contains a roadmap for the development of a new version of vanilla-calendar-pro v3.0.0. The purpose of this version is to add new features, improve performance, and fix known bugs.

• [x] Completely get rid of the dependence of css classes in the code, add full support for Tailwind. #247 #260
• [x] Add the ability to set custom weekends for each week. Use an array to define the week. For example: weekends: [5,6] #286 #291
• [x] Add customizable week start day. #308
• [x] Add the ability to install custom themes created manually. Create a new custom theme.
• [x] Add feature prevent month change when selecting days from another month. #306
• [x] Remove re-render after click in current month. Fix event displaying pop-ups in mobile versions. #287
• [x] Fix calendar grid styles.
• [x] Make the day of the week clickable like the week number.
• [x] Maximize accessibility, add aria labels, tabindex, etc. to the layout. Implement full calendar control from the keyboard. #233
• [x] Add full support for control using keyboard arrows or joystick. 🤩
• [x] Fix date rounding in date range selection mode. #313
• [x] Add maximum and minimum installation time to Time Picker. #234
• [x] Add the ability to select a time range. #232
• [x] Refactoring the calendar settings API. #314
• [x] Perform type refactoring #279
• [x] Add setSettings(...options) method instead of overriding calendar.settings = { ...newOptions } #273
• [x] Add onCreateDateRangeTooltip() #312

For now, this is all that is planned to be implemented in the new version. In addition to the above, it is planned to carry out partial refactoring to optimize the code.

Write your suggestions for the new version in this Issue, thanks for your input and support, whatever it may be. 🙂

[ghiscoding]

For the weekends, if we look at the air-datepicker project, we can change both the weekends and the first day that the calendar begins.

[johanrd]

Nice list! Especially independence of css classes and weekend settings will be powerful!

[uvarov-frontend]

I'm glad to announce that I completely got rid of the CSS class dependency in the new version. #247 #260 Now you can pass any custom selectors in an unlimited number to the CSSClasses object, which allows you to use Tailwind. update/3.0.0, it was a lot of work. Complete code refactoring. I continue to implement other items on the roadmap. I hope I have enough free time to release the release in November.

[uvarov-frontend]

Implemented custom weekends #291 and any custom first day of the week. #308

[uvarov-frontend]

Added a new option to control month switching by clicking on a day from another month #306

[ghiscoding]

Another thing that might be nice to fix is that in Angular, I'm receiving these 2 warnings

the problems is that these 2 files are created by hand and are also included in the GitHub project, it's also why we have to import types differently import type { IOptions } from 'vanilla-calendar-pro/types';. We did discuss this a bit in #279 which you pointed me to the different import for types and the possible breaking change to move types in the default export, it might be a good time to refactor these and fix the warnings. But taking a look at some articles on the internet (like this article), it might be fixable by simply modifying your tsconfig.json and add this (you might need to adjust the path of these files)

{
 "compilerOptions": { ... },
  "files": [
    "./classes.ts",
    "./types.ts"
  ]
}

[uvarov-frontend]

@ghiscoding Added to the roadmap, thanks

[uvarov-frontend]

I've implemented all the new features and fixed all the bugs I'm aware of so far. All I need to do is refactor the calendar settings API and its types for the new version, and add a changeSetting method for the new API.

@ghiscoding Do you have any recommendations for me on how to design a new API and types for the calendar?

[ghiscoding]

@ghiscoding Do you have any recommendations for me on how to design a new API and types for the calendar?

@uvarov-frontend I'm not exactly sure what you mean by designing the new API but if you're rewriting the API then I was wondering if we need to keep all the settings properties as objects? Some of the problems that I had at the beginning when I started using your project was that in Flatpickr (that I was using prior) are all flat options and it's easy to deal with. However in your project if we want to change previous settings, we have to use an object and sometime we have to extend the object to not lose previous settings like below

const vc = new VanillaCalendar('#calendar', {
  selected: {
      dates: ['2022-08-10:2022-08-15', '2022-08-20', 1722152977141, new Date()],
  },
});

// if we want to keep previous selected dates, we need to extend the object
vc.settings.selected = {
   ...vc.settings.selected,
   month: 8
}

if we had flat options (not objects but rather selectedDates, selectedMonth, ...) then we wouldn't need to extend the object. However this could be a big change and also a breaking change, so I'm not sure if it's really something you and others want to change? but that is what comes to mind at the moment. I would surely have to also create a major breaking version on my end too but I would be ok with it anyway but I might not adopt the new version right away even though I would still prefer this approach personally. Could you explain more what you had in mind in terms of API changes?

[uvarov-frontend]

@ghiscoding Do you have any recommendations for me on how to design a new API and types for the calendar?

@uvarov-frontend I'm not exactly sure what you mean by designing the new API but if you're rewriting the API then I was wondering if we need to keep all the settings properties as objects? Some of the problems that I had at the beginning when I started using your project was that in Flatpickr (that I was using prior) are all flat options and it's easy to deal with. However in your project if we want to change 1 setting, we have to use object and sometime we have to extend the object to not lose previous settings like below

const vc = new VanillaCalendar('#calendar', {
  selected: {
      dates: ['2022-08-10:2022-08-15', '2022-08-20', 1722152977141, new Date()],
  },
});

// if we want to keep previous selected dates, we need to extend the object
vc.settings.selected = {
   ...vc.settings.selected,
   month: 8
}

if we had flat options (not objects) then we wouldn't need to extend the object. However this could be a big change and also a breaking change, so I'm not sure if it's really sometime you and others want to change? but that is what comes to mind for now. Could you explain more what you had in mind in terms of API changes?

This is exactly what I'm talking about. I plan to get rid of the object in the settings and plan to use flat options. This is exactly what the vote in which you participated was about. 😀 But I plan to create a migration page on the site from the second version to the third with information about where and what parameter was renamed/replaced. In fact, the only thing that will change is that the parameter will be flat and, accordingly, have a different name.

This needs to be done because some parameters are in an illogical place and, worse, have a strange name.

When I talk about parameters, I mean options.

[ghiscoding]

ah great then I'm all for it. Thanks 😃

[ghiscoding]

Also I guess that renaming all settings to camelCase should be enough, though feel free to rename as you wish (i.e. settings.selected.dates => selectedDates). You could also compare your settings with the air-datepicker project, they also use flat options and some of the previous PRs I've made were based on some of their options, so having similar option names is not a bad thing for easy migration between the 2 projects, which is hopefully external users migrating to your project ;)

I was also wondering does the Tailwind changes you recently made on the customizations of CSS classes, will that going to impact the build size? I don't personally use Tailwind at all and I'm fine with your current light/dark theme, so making it easier to use with Tailwind is nice but I hope it doesn't impact the final CSS build size too much. Loving your project and all of these 3.0 upcoming changes which is going to boost the usability even more, great work. 🚀

hey maybe a final suggestion on a user level, you should add some kind of sponsors (donations) on your page, it could be GitHub Sponsors, Ko-Fi or others depending on availability in your area, I like Ko-Fi, it's free and easy to setup and it's also available on your side, a coffee isn't much but it's always nice to receive ;) Cheers

[uvarov-frontend]

Also I guess that renaming all settings to camelCase should be enough, though feel free to rename as you wish (i.e. settings.selected.dates => selectedDates). You could also compare your settings with the air-datepicker project, they also use flat options and some of the previous PRs I've made were based on some of their options, so having similar option names is not a bad thing for easy migration between the 2 projects, which is hopefully external users migrating to your project ;)

I was also wondering does the Tailwind changes you recently made on the customizations of CSS classes, will that going to impact the build size? I don't personally use Tailwind at all and I'm fine with your current light/dark theme, so making it easier to use with Tailwind is nice but I hope it doesn't impact the final CSS build size too much. Loving your project and all of these 3.0 upcoming changes which is going to boost the usability even more, great work. 🚀

hey maybe a final suggestion on a user level, you should add some kind of sponsors (donations) on your page, it could be GitHub Sponsors, Ko-Fi or others depending on availability in your area, I like Ko-Fi, it's free and easy to setup and it's also available on your side, a coffee isn't much but it's always nice to receive ;) Cheers

Don't worry about Tailwind, I end up creating calendar styling classes the same way as before. And at the output we have the same css files for styling as before, as far as I remember their weight is even less than it was.

The differences are that previously it was possible to specify only one class in CSSClasses for each of the keys, like this: calendar: 'vanilla-calendar', this was necessary since there was a dependence on the specified class when searching for a selector in the code. Now there is no such problem and binding occurs using data attributes. Now you can specify a list of classes from Tailwind in the same key and everything will work without problems: calendar: 'relative box-border min-w-[272px] flex flex-col p-4 rounded-xl opacity-100 transition-opacity'.

This is how I solved the problem for those who want to use multiple classes from Tailwind, I added support for Tailwind, but this does not mean that I made it by default in the project.

I also generated a new color scheme using ChatGPT for some variety. This is what she looks like:

It's called slate-light, in order to use it you just need to specify it as a theme: theme: 'slate-light', by default the themes are the same as before: 'light' and 'dark '. In the future we may create a directory of custom themes, anyone can create a new theme.

[uvarov-frontend]

I created a new API map for all calendar options and actions #316

[ghiscoding]

ah that's great if the CSS size is the same (or even smaller awesome), personally I just use SASS and provide variables to external users if they want to customize the colors and such. It could be nice to have SASS variables to customize a bit more, but I'm also fine without them since we can add our own classes anyway. I quite like the current project colors but I'm not color blind, so maybe ChatGPT gave you these colors because they are better for these users!?

I created a new API map for all calendar options and actions #316

oh nice, looking great, flat options are coming 🚀

[uvarov-frontend]

I quite like the current project colors but I'm not color blind, so maybe ChatGPT gave you these colors because they are better for these users!?

It's unlikely. My request was not related to color blindness)

[uvarov-frontend]

Another thing that might be nice to fix is that in Angular, I'm receiving these 2 warnings

the problems is that these 2 files are created by hand and are also included in the GitHub project, it's also why we have to import types differently import type { IOptions } from 'vanilla-calendar-pro/types';. We did discuss this a bit in #279 which you pointed me to the different import for types and the possible breaking change to move types in the default export, it might be a good time to refactor these and fix the warnings. But taking a look at some articles on the internet (like this article), it might be fixable by simply modifying your tsconfig.json and add this (you might need to adjust the path of these files)

{
 "compilerOptions": { ... },
  "files": [
    "./classes.ts",
    "./types.ts"
  ]
}

@ghiscoding Please check if there are warnings and errors that you mentioned in 3.0.0-beta.9 when importing a calendar in Angular. I was unable to reproduce the problem.

[ghiscoding]

great thanks, I'll give a try to your beta probably next week. Even quickly looking at the end result on unpkg, I don't see these 2 files in the root of the package and so it should be all fine (the error from Angular was because the files where in the root without being referenced in any index.ts or d.ts and that is no longer the case so the error should all be gone). Thanks a lot for all this huge 3.0 refactoring, I will provide feedback next week. Cheers

[uvarov-frontend]

I have everything ready for the release of version 3.0.0, expect it soon.