Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Filter: Add date-range to custom date range filter value component [GAUD-6578] #4764

Merged
merged 2 commits into from
Jun 25, 2024

Conversation

margaree
Copy link
Contributor

Jira ticket

Adds type property which defaults to date-time but can be set to date in order to use a d2l-input-date-range component inside the custom date filter value component.

Copy link
Contributor

Thanks for the PR! 🎉

We've deployed an automatic preview for this PR - you can see your changes here:

URL https://live.d2l.dev/prs/BrightspaceUI/core/pr-4764/

Note

The build needs to finish before your changes are deployed.
Changes to the PR will automatically update the instance.

@margaree margaree marked this pull request as ready for review June 24, 2024 15:23
@margaree margaree requested a review from a team as a code owner June 24, 2024 15:24
* Date/time range input type
* @type {'date'|'date-time'}
*/
type: { type: String }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option would be to have a bool like hide-time. The advantage of type is in case in the future we need to do some sort of time-only range or some other state (though there are currently no plans for those)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of the two, I prefer the type approach for the reason you mentioned.

Another alternative we can contemplate is busting it into two different components, which might be overkill if the API is essentially the same and there isn't much in the way of conditional logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed - at this point (nor going forward) I don't see it as necessary to split them out.

Comment on lines +144 to +145
this.startValue = e.target.startValue ? getUTCDateTimeFromLocalDateTime(e.target.startValue, '0:0') : undefined;
this.endValue = e.target.endValue ? getUTCDateTimeFromLocalDateTime(e.target.endValue, '0:0') : undefined;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d2l-input-date-range values are only localized so this gets the UTC value for midnight on the selected date.

end-value="${ifDefined(this.endValue)}"
label="Custom Range"
label="${this.localize('components.filter-dimension-set-date-time-range-value.text')}"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would (potentially) be the same as the list item text if not set by the consumer. I'll be looking at accessibility in a follow up story so I'll do some testing at that point to see if that's too repetitive.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@margaree margaree merged commit fcd3bd1 into main Jun 25, 2024
6 checks passed
@margaree margaree deleted the filter-date-range branch June 25, 2024 20:17
Copy link

🎉 This PR is included in version 3.18.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants