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.
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
Filter by Date Pt. 2 - Custom date selection #3117
base: main
Are you sure you want to change the base?
Filter by Date Pt. 2 - Custom date selection #3117
Changes from 16 commits
2649c0d
c2a25ce
e611290
d92a516
5c1b5a7
64a27aa
016a23a
61cbc3c
e718ac3
bcb4606
39fd3e8
d634cc4
af0c329
343c944
22d56d1
643400c
ec9a5fa
0b0792e
432bd1e
0902cc2
8f54b1a
5604ed3
77fd9d0
cd4d82b
a8c3aef
96387bb
728618b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this instead be computed from the enum? (is a formal enum worth it or just use a plain object?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just made an update!
(Maybe an enum is overkill, but thought it would make things clearer in case we expand the scope of filters?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need to do this copy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needed to pass params to updateQueryParam in the
submitHandler
(can't pass searchParams which is read-only)Could move Line 139 into the
submitHandler
so it's more clear why that's needed?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this into
updateQueryParams
so it always returns a new params and doesn't mutate. Especially since mutating state can be such a footgun, best to avoid it entirely by defaultThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if a user manually deletes the dates param, it ends up looking like this
should we reset to the default instead at this point? cc @ashton-skylight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what were the pros/cons/thinking on the two param approach vs a single param like
custom(start,end)
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, missed this comment on Friday! My thoughts are below, and I'm definitely open to changing the approach.
I went with two URL parameters to keep things simpler. One shows that it’s a custom date, and the other holds the actual dates. Keeping these definitions separate means we don’t have to deal with extra parsing every time we just need one of them (felt cleaner and easier to work with this approach). Also, having two separate parameters helps keep the radio button option name and the URL param values in sync, which makes it simpler to match what the user picks to what’s in the query string.
Also, keeping custom dates in their own parameter seemed like it would make it easier to extend things in the future—like if we wanted to add time ranges. Saves us from having to dig through and parse a single dateRange parameter if we need to add more customizations down the line.
The main con with maintaining the two parameters is maintaining consistency between
dateRange
anddates
, i.e. making sure thatdates
only exists and is processed whendateRange=custom
, and thatdates
does not exist whendateRange
is set to one of the other predefined date ranges. Using the singledateRange
parameter also to house the custom dates would eliminate this risk.Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That matches what I see as well. We just need to make sure we've got robust handling of the keeping in sync and edge cases there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: This is temporary -- a placeholder alert to safeguard against error where
Start date > end date
. Still working on how to make the custom error tooltip for this / might get brought out into a separate small ticketThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe move this abstraction up one level to
RadioDateOptions
? there's still a bit of "guts" in here that could have a nicer API if it handles the options bit. Then it could just passwhat are all the options
handler for option change
andcurrent option
, which is pretty universal to any set of radio buttonsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcmcgrath13 Made these changes in the last commit if you want to take a look -- but I'm wondering if it's really necessary for this ticket?
I think I still need to keep
RadioDateOption
because of the lone custom date radio option, but then addingRadioDateOptions
feels redundant since it's essentially just passing the same parameters down toRadioDateOption
. (it's just adding an extra layer....?)My preference would be to rollback that commit, but lmk if you have any thoughts on changes I could make so
RadioDateOptions
actually simplifies the logic.