-
Notifications
You must be signed in to change notification settings - Fork 904
feat: Add switches for auto-start and auto-stop #3358
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
Conversation
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.
Looks good to me from the backend perspective!
site/src/components/WorkspaceScheduleForm/WorkspaceScheduleForm.tsx
Outdated
Show resolved
Hide resolved
site/src/components/WorkspaceScheduleForm/WorkspaceScheduleForm.tsx
Outdated
Show resolved
Hide resolved
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.
Left some comments but overall I think this looks great!
@Kira-Pilot fyi on the border - other uses of |
@Kira-Pilot @ammario I changed auto-stop to disallow 0 if it's enabled, and I'm thinking maybe auto-start should work the same way. Currently it's like, you can't have no days checked if you have a start time, but now that there's a switch I figure the logic should be, you have to have a time and at least one day if the switch is on. Does that sound right to you? |
@ammario I'm working on the validation one, and I've found a resetting bug but I'm not sure it's the same one you're describing. I intend for this behavior to happen: Given Auto-start is enabled and I've entered days and a time, But I consider this a bug: Given Auto-start and Auto-stop are enabled and I've entered a number of hours until shutdown, If you think the former case is a problem, let me know! |
The behavior doesn't surprise me. It's when you enable Auto-start again and then the days and time are reset to system default that surprises me. I would expect the days and time to be set to what they were right before I disabled Auto-start.
Yes I agree this is a surprising behavior. |
@ammario okay, it sounds like we mostly agree but there may be one place we're not on the same page: say my Auto-start is set to Mondays at 9am. I go to my schedule to add Tuesdays. But before submitting, I turn Auto-start off, and then back on again. This PR will reset your form to Mondays. I think you're saying it should show Mondays and Tuesdays. My argument for Mondays is that that's your current actual schedule, so when you come back from nothing, you should start there. But I see the argument that you should just go back in time to before you disabled Auto-start. I think implementing it to go back in time to Mondays and Tuesdays will be harder than resetting to Mondays. How strongly do you feel about it? |
I don't feel that strongly about. This PR is an improvement on what exists today so it's mergeable as far as I'm concerned :) |
@ammario @Kira-Pilot I'm close to putting up changes that will persist form state while a section is disabled (easier than I expected!) and fix the bug where one section affects the other. But I'm realizing having the form state persisted might be confusing to the user. The values are still visible when I disable, and so for instance the stop section says "Your workspace will shut down after n hours" instead of "Your workspace will not automatically shut down." But if I submit the form with Auto-stop disabled, my workspace will not automatically shut down. What do you think, confusing or fine? |
I think that is potentially confusing. Can we just clear the validation when they disable? Something like |
@Kira-Pilot removed helper text when a section is disabled so that the grey text isn't lying lol |
This reverts commit a6271ca.
@Kira-Pilot just kidding, that made the helper text override the error text so I reverted it. I'll make a ticket for figuring out the UX. |
const handleToggleAutoStart = async (e: ChangeEvent) => { | ||
form.handleChange(e) | ||
// if enabling from empty values, fill with defaults | ||
if (!form.values.autoStartEnabled && !form.values.startTime) { |
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.
are we checking !form.values.startTime
here to ensure the user didn't fill something out previously?
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.
Yes, so we don't overwrite your values with defaults.
await form.setFieldValue(name, defaults[name as keyof AutoStartSchedule]) | ||
}) | ||
await form.setFieldValue("startTime", defaults.startTime) | ||
await form.setFieldValue("timezone", defaults.timezone) |
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.
We might be able to setValues here and handle these setters in an object: https://formik.org/docs/api/formik#setvalues-fields-reactsetstateaction-field-string-any--shouldvalidate-boolean--void
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.
Yay, thanks!
startTime: string | ||
timezone: string | ||
|
||
autoStopEnabled: boolean |
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, I know we chatted about this yesterday, but why are we including autoStartEnabled
and autoStopEnabled
as form values instead of stateful variables? The API doesn't have a concept of these values, right?
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.
Right. I just thought it was a little cleaner this way:
- validation can go back to being an object instead of a function
- all fields in the form are handled by the form
- now that I'm persisting pre-submission form state, the
formToRequest
functions need to refer to the enabled values to decide whether to send the backend falsey values
And the formToRequest
functions just create values to return rather than passing everything through, so there wasn't a real downside to having extra data in the form.
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.
Sounds good, thanks!
Nice job! This was complicated. I left some questions but as far as I'm concerned, this is good to be merged up. Looks great when I run it locally. Thanks for seeing it through! |
Closes #3051
I don't love the
useEffect
but I'm not sure it's worth refactoring to put more logic in the xservice - open to input.I'd like to have integration tests but they run into routing problems.
Testing
Given I am on the schedule page
When I turn a switch on,
Then the controls in that section become enabled
When I turn a switch off,
Then the controls in that section become disabled (but its values aren't cleared).
Given I save the form with one or both sections disabled,
When I go back to the form from the Workspace page,
Then I see the previously disabled section is still disabled, and its values are cleared (empty, unchecked, or 0).
When I enable Auto-start,
Then I see the default values (9:30 AM, my current timezone, M-F) selected.
When I enable Auto-stop,
Then I see the default value (8) in the input.
Given I enable both sections, give non-default inputs, and save the form,
When I go back to the form from the Workspace page,
Then I see the sections are still enabled and still show the values I selected.
When I disable the sections and then enable them again,
Then I see the values I selected (not the default values).