Support date ranges in calendars

[rszymanski]

Resolves #363

This PR adds support for using range calendars (https://fomantic-ui.com/modules/calendar.html#range). When creating a calendar instance users can now pass the id of calendars corresponding to the start or end of the date range for example:

calendar(
  input_id = "start_date",
  type = "date",
  value = "2020-02-20",
  min = "2020-01-01",
  max = "2020-03-01",
  end_calendar_id = "end_date"
)

calendar(
  input_id = "end_date",
  type = "date",
  value = "2020-02-23",
  min = "2020-01-01",
  max = "2020-03-01",
  start_calendar_id = "start_date"
)

An example app showcasing the new feature has been added to examples/calendar_range

DoD

• Major project work has a corresponding task. If there’s no task for what you are doing, create it. Each task needs to be well defined and described.

• Change has been tested (manually or with automated tests), everything runs correctly and works as expected. No existing functionality is broken.

• No new error or warning messages are introduced.

• All interaction with a semantic functions, examples and docs are written from the perspective of the person using or receiving it. They are understandable and helpful to this person.

• If the change affects code or repo sctructure, README, documentation and code comments should be updated.

• All code has been peer-reviewed before merging into any main branch.

• All changes have been merged into the main branch we use for development (develop).

• Continuous integration checks (linter, unit tests) are configured and passed.

• Unit tests added for all new or changed logic.

• All task requirements satisfied. The reviewer is responsible to verify each aspect of the task.

• Any added or touched code follows our style-guide.

[mdubel]

Did you consider making one widget (function) to create date range? I mean, it makes sense that to display two calendars I create two widgets, but it also seems to me vulnerable (like min date of start calendar if later than max of end) and not dry. How about making it more user friendly by having the wrapper e.g. calendar_range that creates the two widgets with matching id's for the user? It seems to me much more convenient and reliable.

[rszymanski]

@mdubel Thank your the comments! I actually thought about adding a wrapper like this:

calendar_range(
    input_id = "date_range", 
    min = "2020-01-01", 
    max = "2020-03-01",
    start_value = "2020-01-02",
    end_value = "2020-01-05",
    start_placeholder = "Select start",
    end_placeholder = "Select end"
)

That would create 2 calendars with ids: date_range_start , date_range_end.

We might want to take into consideration the following:

• This wrapper removes the flexibility of how we want those calendars to be presented in the UI (for example: in a form horizontally)
• It might be confusing as then in the server we would be using input$date_range_start and input$date_range_end which are implicitly created by the wrapper

Is that more or less what you had in mind or did you have a different idea? :)

[rszymanski]

@mdubel I have added a wrapper in form of a separate component (that way we avoid creating implicit ids). Now you can create a calendar range like this:

        calendar_range(
          input_id = "calendar_range",
          start_value = "2020-02-20",
          end_value = "2020-03-20",
          min = "2020-01-01",
          max = "2020-12-01",
          start_placeholder = "Select range start",
          end_placeholder = "Select range end"
        )

It creates a form with 2 calendars and on the server side the data range values are passed in input$calendar_range which is a vector containing 2 values (similar to the dataRangeInput from base shiny).

The difference is in when events are triggered. A change event is triggered only when the end range changes not whenever any of the calendar values changes. In a Semantic UI calendar range, the end calendar is popped up whenever the start calendar changes. Therefore a change in the start calendar forces an interaction with the end calendar.

Please, let me know if you have other suggestions! :D

[aniaskrzydlo]

I think we should create additional function that uses the original calendar() function and adds new parameters instead of adding the parameters to exported function. It may be confusing, especially that in the examples it seems like the user needs to provide start and end calendar id

[aniaskrzydlo]

I think it should be 'when changing the start date' -> not 'start range'

[aniaskrzydlo]

I would suggest changing 'end range calendar' to 'range end calendar' or 'end date calendar'

[aniaskrzydlo]

I suggest having the same order of the arguments as in the calendar() function: id, value, placeholder, type, min, max

[aniaskrzydlo]

For readability, it's worth extracting this function outside of calendar_range()

[aniaskrzydlo]

It should be: placeholder = placeholder

[aniaskrzydlo]

It should be:

`data-date` = value,

[jakubsob]

@rszymanski I tested the component using examples/calendar_range/app.R and it seems like max doesn't prevent you from selecting a greater value. Works after you update it from server though. min works as expected.

Screen.Recording.2021-11-18.at.14.57.47.mov