Model a better step-flow for "Connect to Stripe" views?

[rosschapman]

I experienced some surprise and confusion when setting up a Stripe Connected Account.

Exhibit A: If we know the Stripe API key is missing, on the Marketplace Configuration page we show a big button to Add a Stripe API key to <space_name>. BUT, this button only takes you to the Space edit screen. I found this surprising because I wasn't sure what to do next.

Exhibit B: The Connect to Stripe still displays even when a Stripe account connected. Is this on purpose?

Presuming the following decision table reflects all the legal states currently, can we update the UI to satisfy all these cases.

has stripe key	has stripe utility	has connected account	output
N	N	N	message to setup Stripe utility and button to /utilities/new and
N	Y	N	message to add stripe key and button to /spaces/<space_name>/utilities/<util_id>/edit
Y	Y	N	message to setup Stripe connected account (with link to Stripe doc?) and button to connect stripe
Y	Y	Y	only show stripe connected message

Observation: Considering the above states as steps, 2 & 3 could be combined into the same view.

🤔 What if a admin changes the api key? Is this a valid case?

has stripe key	has stripe utility	has connected account, but stripe key has changed	output
Y	Y		Y

[zspencer]

Excellent questions!

Re: Exhibit A

It would be ideal if the Marketplace::ManagementComponent had a PaymentOptions section that allowed them to add a new or select an existing StripeUtility.

However, the cheap and dirty way would be to link to space.location(:new, :utility) instead of space.location(:edit) when there is not a Stripe Utility. There should be a way to pass in the utility type via the URL to auto-select the Utility from the drop-down.

Re: Exhibit B

In my happy dream world, the entire setup process happens without leaving this page. Perhaps the "Connect to Stripe" button:

• in Scenario 1: Creates the StripeUtility
• in Scenario 2: Renders the StripeUtility Form to set the API Key, including the link to where to get the key
• in Scenario 3: Offers a link to edit (which replaces it with the StripeUtility Form) and a button to Connect Account
• In Scenario 4: Offers a link to edit (which replaces it with the StripeUtility Form) and a button to Re-Connect Account

Re: Exhibit C

If the Admin changes the API Key, the Account will start being Very Sad; and they won't be able to take orders; however we do not currently have a mechanism for detecting that edge-case (and I'm not toooo worried about it yet)

[rosschapman]

@zspencer I agree that handling a changed key scenario is not something to worry about or make high priority.

Regarding A/B, I'd be interested in refactoring the Marketplace configuration experience to support the entire Stripe setup inline. I'm very green working in Rails FE land in 7+.

[zspencer]

Yea! I think the starting point will be to get familiar with ViewComponent, so you can model the UI in the different states; then we figure out how to connect that to the request/response cycle and database. Because Rails focuses on server-side rendering and HTML-over-the-wire; there's not going to be much (if any) JavaScript to write.

The flow I described will be modifying data in multiple places:

• The utilities table holds the StripeUtility
• The furnitures table holds the Marketplace::Marketplace

Hopefully, we won't need any new database tables; but we may need a new Model to represent a Marketplace::StripeConnection that can appropriately determine tables to update.

[rosschapman]

I have written far too much JavaScript in my life. A respite is deserved. Ok, I'll jump into this and ping y'all when I get deep enough to share a code spike and/or design.

Regarding a Marketplace::StripeConnection object. I think some type of manager object like that makes sense. My mind initially went to a workflow object to coordinate side effects. But if there's any state I want to hold onto, a model might be better. Let's see what emerges.

[zspencer]

Yea, I could see this all be handled with a StripeConnectionWorkflowComponent rather than a StripeConnection Model. I tend to reach for a model first because prior to ViewComponent there wasn't a great way to do any kind of multi-step UI logic.

You'll also notice as you start fiddling with turbo-rails, form_with, render, etc. that there is some expectation that objects passed to helper methods respond to methods like id or persisted? and what not, many of which are provided by ActiveModel::Model.

Anyway! Good luck!

[rosschapman]

there is some expectation that objects passed to helper methods expect objects that respond to methods like id or persisted? and what not, many of which are provided by ActiveModel::Model

Interesting. Noted. 😅