#deadhash
pliant yarrow
unique fjord
Products don't have nested Prices. These objects exist separately. They're only ever associated with each other when an Invoice or Subscription is created
sudden vale
Oh
but then
like
how can I have e.g. large small medium pricing
and get products from stripe with images etc, along with all price options
so I can render than info nicely in React?
@unique fjord
or like how would a way to render it be, not using my theoretical logic because that's how I would do it?
my products
unique fjord
Ah, apologies. I forgot you can set the default_price for each Product, which will make it available via the Product object
sudden vale
Ah, apologies. I forgot you can set the `default_price` for each Product, which ...
yes but how do I get all of the prices 😭
like e.g. the item's small variation price, medium, large
unique fjord
You would want to have a separate Price and Product combination for each. So you'd have a Small Price and a Small Product that are linked, then a Medium Price and a Medium Product that are linked. You can get them via the API via a list all API call: https://stripe.com/docs/api/prices/list
sudden vale
so you're telling me there is no way at all to add price/item variations to a product?
and I also cannot add multiple images to one product I assume?
unique fjord
Each Product is supposed to represent one singular product.
We are developing Product Classes for your exact use-case though: https://stripe.com/docs/api/product_classes. It's not available just yet, but it's on it's way
sudden vale
that's kind of shocking that that's not already a feature
like, how can you have a functional e-commerce site with stripe if you have product variations as of right now other than doing it your weird way!?
unique fjord
We had SKUs, which solved that problem, but those were deprecated in favor of Products and Prices, which is a bit unwieldy for making these product combinations, but allows for a lot more functionality than SKUs did.
It was likely a choice someone had to make between being easy to use or being able to work for every possible use-case
And they chose "every possible use-case" over "ease of use"
sudden vale
I guess, but do you not also think that in my use case - until this product classes thingymabob comes out, the API is just so janky to use?!
like it's taken me 4 hours to get my head around how to do it all with the API syntax
unique fjord
I'd say "complex" is a bit more accurate. For users that have incredibly intricate integrations with edge-cases and multi-faceted payment lifecycles, this type of structure ends up making a lot of sense. For a t-shirt shop, it requires a bit of manual updating when new products come out and a slight learning curve to get up to speed.
Ultimately it's a preference type of thing, but you only have to learn it once after all
sudden vale
I guess
Hold on let me show you some code in like 5 mins to how I approached this
and I (very jankily) got it to work
@unique fjord I did it like this. It's jank, and could use optimising - but this is what I came up with:
it's mainly on lines 14:24, as well as the main logic being on lines 74 to 104.
Let me know what you think 😆
it basically makes it nested
unique fjord
If you were only using the API, then that's not a bad way to do it. That being said, I'd highly recommend just storing this in your own database so you don't have to make a huge list all call to the API every time the page renders 😅
sudden vale
If you were only using the API, then that's not a bad way to do it. That being s...
then that's not a bad way to do it
lol thanks didn't know if it was an unorthodox way of doing things 😭
I think I could also maybe make like a python script that I could (manually) run every time I update my products so that it does all that code and saves it somewhere so I don't have to beam the shit out of the API lol
unique fjord
Right, that's not a bad way to go. That way it only occurs when you're modifying Product/Price combos.