Question: client side state possible?

[mike-hogan]

This is a question really, more than a feature request.

Can primo support client side state, as a svelte store or otherwise?

What I really want to know is could I use primo to build an ecommerce site with a shopping cart that retains state across page navigation?

[mateomorris]

Great question! I've been wanting to try it out to build an ecommerce site but haven't had a use-case yet.

Primo doesn't currently offer a built-in way of maintaining state across page changes, but I've created some sites with app-like functionality and handled their state using Supabase as a backend which would fetch the data on each page load.

But for an shopping cart, I'd probably keep the shopping cart saved locally (using idb-keyval or something similar), especially if its an anonymous account.

Curious if you think those strategies would work for you, or if there's something primo could do make it easier/better.

[mike-hogan]

I think idb-keyval would do the job nicely.

The use case I have is an appointment or booking system. Customer chooses a date and time, then chooses optional accessories, then enters their details, then checks out using stripe., in a four step "wizard" style navigation. Each of those steps adds a bit of state.

What I can't imagine is what the editing experience would be to allow me to author such a journey.

[mateomorris]

Could all of that be inside a single component, or would it be too much code?

What I can't imagine is what the editing experience would be to allow me to author such a journey.

Do you mean as a content editor adding new bookable items?

[mike-hogan]

Could all of that be inside a single component, or would it be too much code?

I think too much code, yes, but also less editable by content editors. due to lack of granularity.

I will have a calendar component, a component to upsell accessories, a component to capture details, and a stripe payment component. But I want the content editor to be empower to rearrange them as they please. For example, start with the details capture, then present the calendar. Or put all four components on one page, discarding the "wizard" style nav.

Do you mean as a content editor adding new bookable items?

No I don't mean that. I assume I can find some way to fetch those from an endpoint.

I mean what I describe in the above paragraph. I have not played with primo enough to understand how, given a calendar component and an accessories component etc, how a content editor could take them, configure, for example, the number of days or months shown on the calendar, configure the navigation order between the components etc.

[mateomorris]

I see. It definitely seems like having them all on the same page would be the best way to ensure the process is simple for content editors to build checkout pages - so they could reorder them or leave some off. Then within the components you would have fields which configure the component (days/months shown, etc). When the user interacts with the component, you could save that state with some combination of

1. Appending query params to the url
2. @rallisf1's idea to save to a site group field variable
3. idb
4. a database

The Stripe component would read that state and I imagine pass it along to stripe; haven't used stripe in a while so not sure what the requirements would be there.

[rallisf1]

I haven't tried it but the following should work:

1. Create a Site field for the functionality you want (e.g. cart) along with its subfields (repeatable:products, text:name, number:quantity, etc)
2. Create your add-to-cart buttons and have the on:click function add the data to the cart variable. You don't have to use export let cart as you would do in normal svelte, site variables are global by default
3. You can use something like paypal express checkout or braintree in your cart page. Remember to clear your cart variable upon order completion.

[mateomorris]

Great idea; hadn't thought of modifying a site field variable like that but it makes a lot of sense.

I just tried doing it and it seemed to work within primo but not on the live site because of the way site field values get passed into components. So I made a small change to make those values global and now it's working as expected (will be in the next update).