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

Wiring up form state and value conversion on submission #2

Merged
merged 10 commits into from
Sep 3, 2019

Conversation

schottra
Copy link
Contributor

@schottra schottra commented Sep 3, 2019

  • Reorganized all the form components into a subfolder.
  • Created ApiContext to do dependency injection of api functions. This lets us mock API calls cleanly in stories/tests without having to hook into Axios and do ugly protobuf encoding of mock responses.
    • Note: I have only switched the hooks in use by this form and its stories to using the api context. Others will be migrated later.
  • Implemented all the logic for selecting the workflow, fetching the launch plans, and using the default launch plan.
    • Note: I will add a launch plan selector in the next PR. For now, it's just using the default launch plan.
  • Form now uses WaitForData where appropriate:
    • The initial form state must wait on fetching our 10 default workflow versions
    • The input rendering must wait on fetching of both workflows and launch plans. Otherwise it's going to render whatever input array we have set (which defaults to empty if no launch plan is selected)
  • Added logic for converting the supported input values to their Literal versions for submission to the backend.
  • Fixed z-index issue with workflow selector when other components are in the form with it
  • Wired WorkflowSelector up to the form
  • Fixed some behavior issues with datetime selector.

LaunchFormWithWFSelector

@schottra schottra requested a review from mrmcduff September 3, 2019 17:20
Copy link

@mrmcduff mrmcduff left a comment

Choose a reason for hiding this comment

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

Approve with nits / questions

/** A form field for selecting a date/time from a picker or entering it via
* keyboard.
*/
export const DatetimeInput: React.FC<InputProps> = props => {
const { label, helperText, onChange, value: propValue } = props;
const value = typeof propValue === 'string' ? propValue : defaultDate();
const value =
typeof propValue === 'string' && propValue.length > 0
Copy link

Choose a reason for hiding this comment

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

Are you restricted from checking the type of this where InputProps is defined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

InputProps.value can be one of several types, so this is guarding against what happens if we pass a type we don't expect.
I have a planned cleanup pass in the future where I may just make all input values strings to simplify the logic a bit (It's also messy in the conversion code that runs on submit)

onChange(dateValue.toISOString());
} else if (stringValue != null) {
Copy link

Choose a reason for hiding this comment

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

!== or are you deliberately coercing? If the latter, would you just want else if (stringValue)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Deliberately coercing. I want to allow empty string through, but not null/undefined.

});
const options = workflowsToWorkflowSelectorOptions(workflows);
if (options.length > 0) {
options[0].description = 'latest';
Copy link

Choose a reason for hiding this comment

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

Is this something that is uniquely assigned here? Like, elsewhere that workflowsToWorkflowSelectorOptions is used, would you expect a nonzero length where the zeroth element is not latest? Just checking to see if this is logic that should be contained in the function itself.

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 is specific to the form. I didn't want to hard-code that logic into the selector options function.

import { dateToTimestamp, millisecondsToDuration } from 'common/utils';
import { Core } from 'flyteidl';
import * as Long from 'long';
import * as moment from 'moment';
Copy link

Choose a reason for hiding this comment

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

It doesn't look like this import is used. Also, I think you've capitalized Moment elsewhere when importing it in this fashion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's used on line 28. My default behavior is to keep the import following the TSLint naming conventions (camelCased import). The one other place I do this, I'm importing and assigning moment.utc as moment so that all usages in the rest of the file are guaranteed to use the utc versions. I probably should do that here as well!

/** Returns a fetchable for the default launch plan whose project/domain/name/version
* match the values in the given WorkflowId.
*/
export function useDefaultLaunchPlan(workflowId: WorkflowId | null = null) {
Copy link

Choose a reason for hiding this comment

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

Should this be organized under hooks somewhere? Or are you keeping ones that are intended only for specific components under that component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm trying to move away from keeping all the hooks in a common folder and instead colocating hooks in the modules that use them.

@schottra
Copy link
Contributor Author

schottra commented Sep 3, 2019

Thanks @mrmcduff ! Since this is a feature branch, I'm going to merge and implement feedback in the next PR.

@schottra schottra merged commit 4bd7cb6 into launch Sep 3, 2019
@schottra schottra deleted the form-submission branch September 4, 2019 18:21
@anrusina anrusina mentioned this pull request Jan 20, 2022
8 tasks
anrusina added a commit that referenced this pull request Apr 27, 2022
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.

2 participants