Guest application implementation

[erikguntner]

Overview

We need to ideate, document and review possible approaches to creating application process components

Detail

This issue outlines a possible approach to creating the components necessary for the application process. I'm sure there are many ways to go about this but this is what I came up with after looking at a couple of examples.

The application can be broken down into 3 main parts as seen in the image below:

1. The application stepper that controls how the user moves through the application and tracks progress (green)
2. The various sections (basic information, contact information, employment, etc.) of the application within the stepper (pink)
3. The review application page

Implementation details

Regarding parts 1 and 2, you can see that as the user moves through the application each page contains a progress bar and 3 buttons that allow them to navigate the form and save data. Inside that, form elements are switched out based on the route/step the user is on. To accomplish this I suggest creating a wrapping component that controls the process of stepping through the form, a progress indicator, handles the storing, submitting, and validating of all form data, and renders an outlet that swaps out the form content. Using a Formik context we can then access the data values with a useFormik hook. Below I've written some pseudo-code to provide an example:

const validationSchema = {
  personalInformation: ...schema,
  contactInformation: ...schema,
}

const ApplicationStepper = () => {
  const [step, setStep] = useState();

  const initialValues = {
    // Application data
  };

  return (
    <Formik
      initialValues={initialValues}
      validationSchema={validationSchema[step]} // validate only the data for the current step
      onSubmit={
        // submit logic, could potentially submit data based on step
      }
    >
      <ProgressBar /> // use steps to determine length
      <form>
        <Outlet /> // swap out content based on route 
      </form>
      <Buttons /> // use input type="submit" and reference form element
    </Formik>
  );
};

const PersonalInformation = () => {
  const {values, handleChange} = useFormikContext()

  return (
    <input />
    <input /> 
  )
}

For the application review page, we can read all data from Formik and render it out in sections with the edit links navigating the users to the corresponding page.

Action Items

• Write tickets breaking this down into smaller tasks

Resources/Instructions

https://www.figma.com/file/BNWqZk8SHKbtN1nw8BB7VM/HUU-Everything-Figma-Nov-2022?type=design&node-id=9669-3122&mode=design&t=vslawtLY5SCk56TJ-4

Formik
Formik Context
useFormik
yup

[paulespinosa]

Hi @erikguntner this is related to Guest Application Form #533, right?

[erikguntner]

@paulespinosa yes

[JpadillaCoding]

I see a key feature is being able to save the current state of the form and being able to come back to complete it later. Took a look at our back end and didn't find this capability- endpoints to retrieve the data from the specific user.
Would this need to get built first or for the scope of this work is it being overlooked and using dummy data?

Also wondering if the questions are made in the front end or brought in through the backend since I saw schemas for intakeQuestion, intakeQuestionSet, etc. Is these related to this application form?

[paulespinosa]

@JpadillaCoding The backend hasn’t been implemented for this feature. The tables mentioned are from a preliminary design from a while back. It’s likely that the database will be refactored when the backend is implemented.

[JpadillaCoding]

Just a rough idea based on the epic and our meeting. Let me know if I'm missing something or need any modification based on the complexity of the ticket items. Also, I think we should write these tickets as we go and we're figuring out what's needed while using this as a rough outlook of the task and things needed.

• TICKET- setup the guest application link on the guest dashboard side nav and the formik context for stepping through the application, buttons for continue and back (refer to reset password context file)
• TICKETS- Create the forms - broken up into sections
• TICKET- form completion logic. The auto-population feature if a user is returning. User should also be taken to the current step they're on
• TICKET- Form completed landing page along with sending the user a copy of the form(email/pdf)
• TICKET- Preview landing page along with editing capabilities and submitting all data
  -would this be in the preview page or will the user get taken back to that page for edits?
• TICKET- Functionality of the buttons for saving data. Each page is saved individually.
• TICKET- Validation of data feature for the data of each page along.

[tylerthome]

@JpadillaCoding @johnwroge let's discuss where this stands, and whether remaining child items should be rolled into a new issue or appropriate to continue tracking here

[JpadillaCoding]

@tylerthome We can still use this for tracking this issue. With Tyler's implementation of the intake fields #672 . We should start making more progress on these items. I believe @johnwroge is using Tyler's intake field branch to make the forms and also I'm currently integrating the buttons onto his branch.