[Exploration] Figure out what wicked gives us vis a vis the partner profile form

[cielf]

Summary

We want to rework the partner profile into a step-wise form, with error checking at each step. Figure out if wicked will give us everything we need for that

Details

See concept below. At each "save and next", we would want to be able to check the 'local' fields and display any relevant errors, at "Submit for approval", check the whole thing.

Some specific questions

Are we going to be able to validate as we go along, or only at the very end, using server-side validations? Are we going to be able to go to any sub-section at will, or are we constrained to forward-and-back? Can we save intermediate results ? Is wicked being maintained ?

Criteria for completion

• [ ] explore wicked -- will it do the job?
• [ ] report back to planning meeting (Sunday 10am Eastern Time)

Bonus round

• [ ] Is there something else that we should look at instead?

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[kiranbpatil]

Can I take this one?

[awwaiid]

Yes please! Thank you @kiranbpatil

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[cielf]

Hey @kiranbpatil IIRC you gave a preliminary report back on this, but we didn't, alas, make a record of what you said. Could you add a summary here, please?

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[cielf]

IIRC, yes, wicked will give us what we want, but it might be overkill? Next steps are probably to really throroughly spec out the behaviour.

[cielf]

This needs to be revisited, i'm afraid.

[awwaiid]

@kiranbpatil can you remind us what our conclusion was?

[elasticspoon]

I'm not an expert with wicked or anything but I've been dealing with a bunch of wizard related stuff in rubyforgood/casa, so I think I can answer the basics here.

I will also note that in my experience, wizards typically span multiple pages rather than exist on a single page with accordions for each step. I think turbo frames can probably make it work.

Q and A

Q: Is wicked overkill? A: I can't really answer whether or not this is overkill. It seems like a pretty reasonable place for a wizard.

Q: Are we going to be able to validate as we go along? A: Yes. You can validate at each step. You will need to implement the validation on the models themselves. Wicked abstracts away some of the complexity at a controller/ view level.

Q: Are we going to be able to go to any sub-section at will? A: Yes. There are both view and controller helpers to skip between steps.

Q: Can we save intermediate results? A: Yes.

Q: Is wicked being maintained? A: It has not had a major version release in a while but the project is receiving commits.

Implementation

A general overview of how it works:

• You declare the steps of the wizard: :agency_info, :social_media etc.
• you create nested views for each step: form/agency_info, form/social_media, etc
• you had a field to the org model to track how far into the wizard you've gotten: validates :status, inclusion in [:agency_info, etc]
• you add validations to the model based on where it is in the wizard: validates :something if :agency_info

The typical flow with the wizard might be something like:

• org_controller#new creates a new org with status: agency_info.
• redirects to org_form_controller with that created org
• that controller handles each page by updating the object
• if the update happens while the object is on the last step, it calls some separate method to finalize the org

[cielf]

@elasticspoon Thank you very much for your input! @awwaiid, @dorner -- can you take a look at the above and we can discuss in the planning meeting?

[dorner]

yup. I'm kind of wondering what wicked gives us on top of just adding the status and the controllers ourselves. Seems like a pretty simple update flow. I just don't want to pin us to another external dependency if we're not really squeezing something important out of it.

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions[bot]]

Automatically unassigned after 7 days of inactivity.

[danielabar]

Another thought re: validation, ActiveModel can be used to create an abstraction of the data to be collected at each step/card, then validate just that part at that step.

The idea is in this blog post, and it wouldn't require adding a dependency: https://www.codewithjason.com/rails-multi-step-forms/

[dorner]

Yep - I'm partial to POROS (plain old Ruby objects) wherever possible. ActiveModel validations is a good add-on.

[cielf]

Next action for this is to rewrite as an issue for execution with a couple of the subtleties (submit for approval only at end, some kind of progress indicator) that we mentioned today, then to close this. That's on my plate.

[danielabar]

I could pick this up if it's still available?

[cielf]

I've got the writeup waiting in our backlog, I'll make a note to prioritize it for this Sunday's grooming. Do you want to take on #3052 in the meantime, since you've got most of the knowledge for that fresh?

[danielabar]

Absolutely I could pick up #3052 first.