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

INN 2988 add relative time filter to runs #1320

Merged

Conversation

anafilipadealmeida
Copy link
Contributor

@anafilipadealmeida anafilipadealmeida commented May 3, 2024

Description

  • Add Relative time filter (to be changed when we introduce absolute time filter)
  • Wire timeField filter, now the API is released
  • Change structure of Select options, to allow disabled options
Screen.Recording.2024-05-07.at.13.21.53.mov

Motivation

  • Relative time url params have to be days, rather than start and end times, as when we refresh the page, we want to keep a relative date.
  • Once we add the filter for absolute dates, we need to improve the validation experience (what happens when we want to filter by a range that the current plan doesn't support)

Type of change (choose one)

  • Chore (refactors, upgrades, etc.)
  • Bug fix (non-breaking change that fixes an issue)
  • Security fix (non-breaking change that fixes a potential vulnerability)
  • Docs
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality not to work as expected)

Checklist

  • I've linked any associated issues to this PR.
  • I've tested my own changes.

Check our Pull Request Guidelines

Copy link

linear bot commented May 3, 2024

Copy link

vercel bot commented May 3, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
ui ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 8, 2024 8:41am

Copy link
Member

@djfarrelly djfarrelly left a comment

Choose a reason for hiding this comment

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

Looks good - only real suggestion for the future is to add a generic to Select 👍

Comment on lines +31 to +41
type Props = SelectProps & (MultiProps | SingleProps);

export function Select({
defaultValue,
label,
isLabelVisible = true,
children,
onChange,
multiple,
}: SelectProps & (MultiProps | SingleProps)) {
className,
}: Props) {
Copy link
Member

Choose a reason for hiding this comment

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

suggestion (non-blocking): This can be for future, but it might be nice to allow Option or it's id to be a generic type that can be passed to the Select component (ex. Select<T>(...). That way there could be less type checking in components that use Select and pass an onChange handler. We might then be able to drop the if (isFunctionTimeField(option.id)) {... checking in the other components.

// const [untilTime, setUntilTime] = useSearchParam('until');

/* TODO: When we have absolute time, the start date will be either coming from the date picker or the relative time */
const [startTime, setStartTime] = useState<Date>(new Date());
Copy link
Member

Choose a reason for hiding this comment

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

suggestion (non-blocking): Probably doesn't matter with the TODO here, but will this cause issues b/c new Date() will return a new value every time this component renders? I don't know if it needs to be memo'd or we can just forget it for now until the date picker is there?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think startTime should be derived (and memoized, like you're suggesting) from the URL state. If the URL has something like relative=5h then startTime would be 5 hours ago. If the URL has something like startTime=2024-05-07T11:22:33Z then it would be new Date("2024-05-07T11:22:33Z").

Also, should we rename startTime? It's kinda confusing since it reads like it's related to "started at" when it's really the lower time bound for whichever time field is used (queued, started, or ended)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@goodoldneon was making a good point about always inferring the value from the URL, even if they are the initial defaults that users didn't select. That means changing the behaviour so that the defaults in filters are now also part of the URL, and drop the need for this state. I'll make that change either with pagination or the absolute time work

@anafilipadealmeida anafilipadealmeida merged commit 4be9b44 into main May 8, 2024
13 checks passed
@anafilipadealmeida anafilipadealmeida deleted the ana/inn-2988-add-relative-time-filter-to-runs branch May 8, 2024 08:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants