Add labels option to calendar range#375
Open
AKostiv8 wants to merge 1 commit intoryszard.support_for_calendar_rangesfrom
Open
Add labels option to calendar range#375AKostiv8 wants to merge 1 commit intoryszard.support_for_calendar_rangesfrom
AKostiv8 wants to merge 1 commit intoryszard.support_for_calendar_rangesfrom
Conversation
aniaskrzydlo
suggested changes
Aug 23, 2021
Contributor
aniaskrzydlo
left a comment
There was a problem hiding this comment.
I think we don't have a task in the backlog for this change, so please add the task, or if it's there just link it to the PR.
The functionality works well, I've just added two suggestions to change description and the order of arguments.
| #' @param min Minimum allowed value in both calendars. | ||
| #' @param max Maximum allowed value in both calendars. | ||
| #' @param start_label Label text in the start calendar. | ||
| #' @param end_label Label text in the end calendar. |
Contributor
There was a problem hiding this comment.
How about changing the descriptions to 'Label to be displayed with the start calendar' and 'Label to be displayed with the end calendar'?
| calendar_range <- function(input_id, type = "date", start_value = NULL, end_value = NULL, | ||
| start_placeholder = NULL, end_placeholder = NULL, min = NA, max = NA) { | ||
| start_placeholder = NULL, end_placeholder = NULL, min = NA, max = NA, | ||
| start_label = NULL, end_label = NULL) { |
Contributor
There was a problem hiding this comment.
I've checked that in the majority of inputs we keep the order of arguments the same as in basic shiny inputs, this is: id, label, value/choices. How about putting the labels after the input_id argument?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Short description (with a reference to an issue).
This PR adds users an opportunity to add label(s) about the calendar_range input fields, as for now it is quite complicated to add labels above start and end calendars fields precisely.
In general, to existing
calendar_rangefunction added two argumentsstart_labelandend_labelThe example app showcasing has been also completed.
examples/calendar_rangeDoD
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.