#pl_invoice-types
1 messages ยท Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1276221920194597015
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
We don't really document well what is and isn't nullable. I'd recommend defensive programming and always assuming things could be null or absent
In the Invoice returned in this use case, the attributes that you want to know whether they are nullable or not are
object.amount_due
object.created
object.currency
object.period_end
object.period_start
object.total
object.lines.data[i].amount
object.lines.data[i].currency
object.lines.data[i].description
object.lines.data[i].period.end
object.lines.data[i].period.start
object.lines.data[i].price
Whaat I'd recommend is looking at the types in stripe-node otherwise in https://github.com/stripe/stripe-node/blob/master/types/Invoices.d.ts#L164 and they can give you that information. But again this isn't really a guarantee we make. We should be able to do but we don't
pl_invoice-types
There are many different use cases, so it is inevitable that many are defined as nullable in the unified Invoice object.
However, in a defined use case such as this one, I think it is uniquely defined, so in this case the answer is possible, isn't it?
I mean sure it's fair to think that but it's not the case, I can't really give you a guarantee further than what the types I shared show. If I were in your shoes I'd program defensively and assume things can be null
but in theory I would say none of those can be null other than object.lines.data[i].description which matches what the types say https://github.com/stripe/stripe-node/blob/master/types/InvoiceLineItems.d.ts#L37
I was looking at the community types in rust, but I see that the types in the npm library you are creating in stripe are better. But I guess it is still just for reference.
well it comes from our official openapi spec https://github.com/stripe/openapi which is itself generated from our internal code.
but it's still "best effort"
for example we don't consider that a property like description becoming nullable is a breaking change
for example we don't consider that a property like description becoming nullable is a breaking change
What do you mean? This is still nullable, isn't it?
Yes but if it wasn't, it's a string for a customer-facing description and so if it wasn't nullable and we wanted to add that in the future we wouldn't consider this a breaking change in our API
You're talking about when it goes from nullable to not null, right? Strictly speaking, I think it is a destructive change, but even now the docs don't state it explicitly, so I imagine such a change will happen.
Incidentally, I think it's inevitable that destructive changes will be made on their own (i.e. the platform itself will be upgraded), but is there any way to follow this at the IF level? If I watch this repository, will it be updated almost in real time?
No I was explicitly talking about going from non nullable to nullable
If I watch this repository, will it be updated almost in real time?
I mean it will help but no it's not real time. And again it's best effort. Sorry for sounding like a broken record but really we don't make those guarantees today and you need to be resilient to changes like this.
Ah, I thought it was the other way round because the description I was told earlier was now nullable. Even in that case the docs don't mention whether it is nullable or not, so I am aware of changes in that direction.
https://docs.stripe.com/api/invoices/create_preview
I don't think it's completely real-time, not. But it would be a few days at most? (On average, but that's fine).
yes but again it's not a guarantee. Sorry I don't know how else to say this at this point ๐
No problem. It would be difficult on the world's largest platform like this, and I think Stripe is doing the best it can.
My question has been answered. Please close. Thank you very much.