🌸✨ Marketplace: Shopper chooses DeliveryArea

[zspencer]

• EPIC: Marketplace - Improve the checkout experience #1672
• 🥔✨ Marketplace: Delivery #1325
• 🗺️ Marketplace: DeliveryArea #1136
• 🥔✨ Marketplace: Buying 🥡 Products #1326

So, in reviewing a bunch of the delivery app workflows, most of them have:

• Choose Pickup or Delivery
• Enter Address
• Browse Menu
• Tap Item
• Add Item to Order

This lends me to believe we want to switch to gathering the DeliveryArea then DeliveryAddress then showing the Products that are available.

This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching turbo_frame_tags`).

Blerg; anyway, I'm checking this in now; but not sure if I like it enough.

Thoughts? In particular:

• Copy-editing
• Design tweaks?
• Name Collisions: How Undo?

After!

Video

Screen.Recording.2023-08-14.at.12.51.36.PM.mov

[zspencer]

If I could get some review on the direction that would be appreciated; even though the tests aren't passing yet.

[rosschapman]

Experience tells me that each section of the checkout experience needs a more human friendly heading that addresses the shopper in a conversation. For example, instead of just "Delivery Area" for the new delivery selection area you would have "Choose your delivery area" -- also that heading stays in edit or persisted mode. And for next section "Add items to your cart" or something. The latter would replace Name/Description/Price table-style headings.

[zspencer]

I like the idea of putting some headings! @anaulin has been advocating for splitting the Cart and the Products into their own pieces; which I think is the logical next step.

How about:

<Card>
  <h3>Delivering To</h3>
  <select>...</select>
</Card>

[rosschapman]

@anaulin has been advocating for splitting the Cart and the Products into their own pieces; which I think is the logical next step.

Makes sense, especially for when product lists start to get longer. Like adding a "View cart" button or panel pinned to the bottom of the screen which pops up a summary overlay. I literally built this for ticket purchasing at Eventbrite 😂

[zspencer]

I feel like this should maybe be inside the CardComponent? And then the form shouldn't have a CardComponent around it...

So we wind up with

<Card>
  <TurboFrame>
    <%- if delivery_area.present? %>
      <Cart::DeliveryArea cart />
    <%- else %>
      <Cart::DeliveryAreaForm cart />
    <%- end %>
  </TurboFrame>
</Card>

[zspencer]

@zinc-collective/convene-maintainers and @zinc-collective/convene-contributors - I am marking this as ready for review, since it has test coverage on the new endpoints.

[anaulin]

How would one land one this show page? I can't find any links to a standalone show page in this PR.

[zspencer]

When Turbo fails (or a Shopper disables it... or they command + click/open in a new tab), submitting cart/delivery_areas#update redirects them to the cart/delivery_areas#show endpoint.

[anaulin]

Thanks for clarifying!

[anaulin]

I think this makes a lot of sense as our general product direction: ask for delivery area first, then display delivery costs, ordering windows, etc, depending on that, even before the shopper starts adding things to the cart.

Noodling out loud, for a future iteration, it would be nice to:

• prompt the shopper more clearly to select the delivery area before they can do anything else (maybe even like a modal overlay)
• if there is only 1 delivery area in the marketplace, select that for them automagically and don't prompt them to select anything

(See my question below about where is the show page with breadcrumb shown.)

[zspencer]

prompt the shopper more clearly to select the delivery area before they can do anything else (maybe even like a modal overlay)

Agreed.

if there is only 1 delivery area in the marketplace, select that for them automagically and don't prompt them to select anything

Ya! I'm going to do that in a follow-on PR!