Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always encode arrays as integer-indexed hashes #565

Merged
merged 1 commit into from
Feb 14, 2019
Merged

Always encode arrays as integer-indexed hashes #565

merged 1 commit into from
Feb 14, 2019

Conversation

ob-stripe
Copy link
Contributor

@ob-stripe ob-stripe commented Feb 13, 2019

r? @brandur-stripe @rattrayalex-stripe
cc @stripe/api-libraries

Always encode arrays as integer-indexed hashes. This is the default behavior of qs.stringify(). Stripe's API can now accept integer-indexed hashes for all array parameters (including expand) so there is no longer a need to special-case arrays of hashes parameters like subscription_items.

I've also updated the encoding method to change square brackets back to their literals to make the strings easier to read. This is consistent with most of our other libraries.

Fixes #561.

Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks so ✨ !

Few quick questions

{plan: 'potato'},
{plan: 'rutabaga'},
{id: 'SOME_ID', deleted: true},
],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm somewhat worried about our test coverage reduction here... is there anything in our test suite to verify that these POST bodies are form-encoded with subscription_items[0][plan] instead of subscription_items[][plan] ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair! Looking into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so this is difficult to test in the current state. The URL-encoding of the request parameters happens in the original _request method, but getSpyableStripe() returns an instance of stripe where _request is patched to memorize the method parameters instead of actually sending the request.

We've recently added nock for testing the telemetry stuff, so we could probably write some new tests that use it to check the actual body of our HTTP requests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think nock sounds like the right tool for this job, should be pretty straightforward - fft DM me or paul if you need help with it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I lied, we didn't add nock at all. No idea why I thought that was the case!

Nevertheless, I tried writing a test with nock to test StripeResource._request, but I can't seem to have nock intercept the request -- for some reason the request is always sent to the real API server. Mind giving it a try @rattrayalex-stripe?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We add nock in #559 😄

test/utils.spec.js Show resolved Hide resolved
test/utils.spec.js Show resolved Hide resolved
test/utils.spec.js Show resolved Hide resolved
@rattrayalex-stripe
Copy link
Contributor

rattrayalex-stripe commented Feb 13, 2019

LGTM

Actually, yeah, would be a big +1 to using nock to write a test for POST bodies

@ob-stripe
Copy link
Contributor Author

@rattrayalex-stripe I added a couple of encoding tests in StripeResource.spec.js, ptal.

Unfortunately, for GET requests, it seems nock doesn't let you check the raw query string -- instead, it uses qs itself to decode the query string into an object. I'd have preferred to check the encoded string directly just in case qs' logic differs from Stripe's in subtle ways, but that doesn't seem to be possible.

Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For GET requests, I believe gives you the path with query, but that's fine because we test GET querystrings elsewhere.

One clarifying question that I'm fairly sure has the answer I'm looking for; assuming so,

LGTM

test/StripeResource.spec.js Show resolved Hide resolved
@ob-stripe ob-stripe merged commit 713cdcb into master Feb 14, 2019
@ob-stripe ob-stripe deleted the ob-561 branch February 14, 2019 17:56
@ob-stripe
Copy link
Contributor Author

Released as 6.25.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants