fleet/frontend/components/forms
jacobshandling 5d9026b7e5
UI - GitOps Mode: Core abstractions, first batch of applications (#26401)
## For #26229 – Part 1


![ezgif-6bbe6d60c12ed4](https://github.com/user-attachments/assets/37a04b64-abd7-4605-b4ac-9542836ff562)

- This PR contains the core abstractions, routes, API updates, and types
for GitOps mode in the UI. Since this work will touch essentially every
part of the Fleet UI, it is ripe for merge conflicts. To mitigate such
conflicts, I'll be merging this work in a number of iterative PRs. ~To
effectively gate any of this work from showing until it is all merged to
`main`, [this commit](feedbb2d4c) hides
the settings section that allows enabling/disabling this setting,
effectively feature flagging the entire thing. In the last of these
iterative PRs, that commit will be reverted to engage the entire
feature. For testing purposes, reviewers can `git revert
feedbb2d4c25ec2e304e1f18d409cee62f6752ed` locally~ The new settings
section for this feature is feature flagged until all PRs are merged -
to show the setting section while testing, run `ALLOW_GITOPS_MODE=true
NODE_ENV=development yarn run webpack --progress --watch` in place of
`make generate-dev`

- Changes file will be added and feature flag removed in the last PR

- [x] Settings page with routing, form, API integration (hidden until
last PR)
- [x] Activities
- [x] Navbar indicator
- Apply GOM conditional UI to:
    - [x] Manage enroll secret modal: .5
    -  Controls >
        - [x] Scripts:
        - Setup experience > 
            - [x] Install software > Select software modal
        - [x] OS Settings >
            - [x] Custom settings
            - [x] Disk encryption
        - [x] OS Updates
 
2/18/25, added to this PR:

   - [x] Controls > Setup experience > Run script
   - [x] Software >
        - [x] Manage automations modal
        - [x] Add software >
            - [x] App Store (VPP)
            - [x] Custom package
   - [x] Queries
        - [x] Manage
        - [x] Automations modal
        - [x] New
        - [x] Edit
   - [x] Policies
     - [x] Manage
     - [x] New
     - [x] Edit
     -  Manage automations
       - [x] Calendar events


- [x] Manual QA for all new/changed functionality

---------

Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
2025-02-20 08:41:07 -08:00
..
ChangeEmailForm Frontend: Cleanup 42 js warnings (#16219) 2024-01-23 09:16:10 -05:00
ChangePasswordForm UI – refactor forms and form fields (#16159) 2024-01-18 10:48:44 -05:00
ConfirmInviteForm UI – Updates to confirm invite flow (#25583) 2025-01-24 10:55:39 -08:00
ConfirmSSOInviteForm UI – refactor forms and form fields (#16159) 2024-01-18 10:48:44 -05:00
fields UI - GitOps Mode: Core abstractions, first batch of applications (#26401) 2025-02-20 08:41:07 -08:00
ForgotPasswordForm UI – refactor forms and form fields (#16159) 2024-01-18 10:48:44 -05:00
FormField Fleet UI: Filter software/version tables by vulnerability score and exploitability (#21278) 2024-08-20 09:41:49 -04:00
LoginForm Fleet UI: 2FA (#24442) 2024-12-05 15:54:43 -05:00
packs UI – refactor forms and form fields (#16159) 2024-01-18 10:48:44 -05:00
RegistrationForm Frontend: Improve URL and email validation (#18445) 2024-04-25 13:03:30 -04:00
ResetPasswordForm dont show SQL errors in the UI (#19898) 2024-06-25 11:38:40 +01:00
UserSettingsForm Fleet UI: Disabled styling fixes (#19614) 2024-06-11 11:11:40 -04:00
validators Fleet UI: 2FA (#24442) 2024-12-05 15:54:43 -05:00
_styles.scss Bring new style variables from teams into master (#707) 2021-04-30 17:32:50 -04:00
Form.jsx Client side search for tables no longer debounce (#2807) 2021-11-04 21:16:42 -07:00
README.md Replace uses of the term "Kolide" with "Fleet" (#1999) 2019-01-24 09:39:32 -08:00

Fleet Forms

Fleet Forms leverage the Form Higher Order Component to simplify implementation and state management. As a user fills out a form, the Form HOC collects the form data in state. When the form is submitted, the Form HOC calls the provided client-side validation function with the form data and, if valid, then calls the handleSubmit prop with the form data. If the client-side validation function returns errors, those errors are stored in the Form HOC state and displayed in the form input where the input name matches the error key.

The Form HOC takes 3 parameters:

  • Component Class: The Component Class is the individual form component. It is a React component that renders a form.
  • Options Hash: The Options Hash accepts 2 options:
    • fields: This option is an array of field name strings in the form.
    • validate: This option is a function that gets called with the form data to test validity of the form. The return value from the validate function is expected to be a Javascript object with a valid key that has a boolean value signifying whether or not the form is valid, and an errors key that has a Javascript object value containing the client side validation errors.
      type ValidateResponse = { valid: String, errors: Object };
      const validate Function = (formData: Object): ValidateResponse => { ... };
    

The Form HOC renders with Component Class with additional props. The added props to the form are:

  • fields: The fields prop is a Javascript object containing an object for each field string passed to the Form HOC in the fields array. Each field object contains the following:
    • error: A string containing client side validation errors from the validate function or from the serverErrors prop passed to the form.
    • name: The name of the form field.
    • onChange: A function used to handle change on a form field element. This function stores the value of the form field element in state, and then submits the form field element values when the form is submitted.
    • value: The value of the form field element.

Additionally, the Form HOC accepts the following props passed to the form instance:

  • serverErrors: A Javascript object containing errors returned by the server. The key should be the name of the form field and the value should be the error message string. (Defaults to {}).
  • formData: A Javascript object representing the entity that will populate the form with the entity's attributes. When updating an entity, pass the entity to the form as the formData prop.
  • handleSubmit: A function that is called when the form is submitted. The function will be called with the form data if the validate function is run without errors.
  • onChangeFunc: A function that is called when a form field is changed. It is passed 2 parameters, the form field name and value. This is useful for handling specific form field changes on the parent component.

Example:

// Defining the form

import Button from 'components/buttons/Button';
import Form from 'components/forms/Form';
import InputField from 'components/forms/fields/InputField';

class MyForm extends Component {
  render () {
    return (
      <form onSubmit={this.props.handleSubmit}>
        <InputField
          {...this.props.fields.first_name}
        />
        <InputField
          {...this.props.fields.last_name}
        />
        <Button type="submit" />
      </form>
    );
  }
}

export default Form(MyForm, {
  fields: ['first_name', 'last_name'],
  validate: (formData) => {
    return { errors: {}, valid: true };
  },
});


// Rendering the form
import MyForm from 'components/forms/MyForm';

class MyFormPage extends Component {
  handleSubmit = (formData) => {
    console.log(formData);
  }

  render () {
    return (
      <div>
        <MyForm handleSubmit={this.handleSubmit} />
      </div>
    );
  }
}

export default MyFormPage