[Enhancement] Addition of new properties to the Calendar component

[felipetesc]

Description

Currently the Calendar component can't prevent users from selecting certain days. That is, we can click on any cell and the day will be selected. Also we can't customize the month names and the week days.

Suggested Solution

My suggested solution involves the addition of some new fields to the Calendar, such as

# for German
Calendar(
   #German months
    month_names=['Januar', 'Februar', 'März', 'April', 'Mai', 'Juni' ,'Juli', 'August',  'September', 'Oktober','November', 'Dezember']
   
   # German week days: Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntag
   # For german we could rename the week days such as the ones below
   week_days= [ 'Mo', 'Di', 'Mi', 'Do', 'Fr', 'Sa', 'Si' ], 
   
  # the user will be able to select only Montag, Mittwoch, and Donnerstag, because the other weak days the biz isn't opened
  # I'm not considering week days as an array which starts by 0
  valid_days=[1, 3, 5],  

)

Calendar(
   #Portuguese months
    month_names=['Janeiro', 'Fevereiro', 'Março', 'Abril', 'Maio', 'Junho' ,'Julio', 'Agosto',  'Setembro', 'Outubro','Novembro', 'Dezembro']
   
   # Portuguese week days: Domingo, Segunda, Terça, Quarta, Quinta, Sexta, Sábado
   # The first day of the week starts with Sunday
   week_days= [ 'Do', 'Seg', 'Ter', 'Qua', 'Qui', 'Sex', 'Sab' ], 
   
  # the user will be able to select only Segunda, Quarta, and Quinta, because the other weak days the biz isn't opened
  # I'm not considering week days as an array which starts by 0
  valid_days=[2, 4, 5],
)

month_names : Array of str
week_names : Array of str
valid_days : Array of ints

Alternatives

Perhaps customizing input type="date with Rio theme will prove easier an quicker to maintain. However, the level of control will decay.

Additional Context

I've looked into calendar.ts inside rio/frontend/code/components and I noticed the properties: monthNamesLong?: Array<string>, and dayNamesLong?: Array<string>. If those props are made public to Python, we can easily customize month and week days. Also there are some methods which might need some changes:

• updateElement; so we don't select some days: adding a new SCSS rule perhaps ? for invalid week days
• updateGrid: call new week days inside for loop, change classes.push("rio-calendar-selected-day") to something like classes.push("rio-calendar-unselected-day") for days we cant select

Related Issues/Pull Requests

None, I've searched at Discussions, Issues and Discord.

[mad-moo]

I kind of like this, but also have some reservations.

1. The day and month names are taken from the user's system. (They're sent to Python the first time a user connects.) What's the use case for telling the user which language they must speak?

2. When limiting the valid dates I feel like arbitrary code must be allowed to run. What if someone wants to disallow past dates? Holidays? Allow dates by moon phase? You get the idea 😄

This raises the question of what makes this component special? When you don't want to allow some input in a rio.TextInput, you can listen for changes and decline any you don't like simply by overriding the value. You can do the same thing here.

However, it would be very nice to display which days the user can click on, so they can see what valid days are before interacting so there is definitely value here.

Sorry for the ramble. I'm torn

[felipetesc]

Hello. Thanks for the quick answer. About number 1: sometimes we are at cafés, traveling, and using PCs from other people, and maybe in certain situations an user can't change the language of the system.

[iwr-redmond]

There's an LGPL-licensed package called temporal that can do some of the calculations suggested here. It's being reorganized at the moment, so reading through the code isn't as rewarding as it could be. However, you can get a good idea about what it can do by looking at the index of functions in __init__.py.

Together with the aptly named holidays library, you could go some way to allowing for custom date calculations without permitting arbitrary code, which I agree would be bad.

This code might make a good example extension.