-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Use stripe.setAppInfo to identify ReactionCommerce to Stripe (fixes #57) #4942
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
Use stripe.setAppInfo to identify ReactionCommerce to Stripe (fixes #57) #4942
Conversation
4e1df50 to
0c998ab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rattrayalex-stripe Thanks for the PR! As far as I understand, your goal is for everyone who builds a Reaction-based app and uses Stripe to be sending the same name value, correct? If so, hard coding the value actually makes more sense than an environment config because you want to discourage anyone changing it. In fact, I'd add a comment above the name property requesting that they do not change it.
The one other change I request is to create a single util file in which the object is built. You can add a file /imports/utils/appInfo.js:
import packageJson from "/package.json";
/**
* This is used by Stripe plugins, but may also be useful for other code.
* Do not change the `name`.
*/
const appInfo = {
name: "ReactionCommerce",
version: packageJson.version,
url: packageJson.url
};
export default appInfo;Then import that everywhere and do stripe.setAppInfo(appInfo);
|
Thanks so much, @aldeed ! Staring at this a bit more, I had a few thoughts:
Accordingly, I centralized things a bit with one Additionally, I'm considering a follow-on refactor to deduplicate/unify Totally happy to go with your originally suggested solution of Mind taking another look @aldeed ? Oh, and to be clear,
Yes that's correct π |
Signed-off-by: Alex Rattray <[email protected]>
94e2fab to
0839533
Compare
aldeed
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rattrayalex-stripe All good points.
- The top of
getStripeInstanceForShopis essentially the same asgetStripeApiKey, so they could be combined, but you'd have to have it return theapplicationFeeas well which is something that only applies to marketplace. (Marketplace supports Stripe Connect so that sub-shops can use the primary shop's Stripe account and the primary shop can take a cut of sales. That's currently the only difference.) - The
|| stripePackage.settings.connectAuth.access_tokenpart ingetStripeApiKeyin the non-Marketplace package shouldn't be necessary because as I mentioned, Connect is only used in a marketplace setup. Those plugins used to be combined so it's probably a leftover from then. - FYI The reason there's so much code duplicated is because the marketplace plugin is no longer supported and the plan is to move it to a separate community-owned repo in the near future.
- Combining
getStripeApiKeyandgetStripeInstancecalls intoawait getStripeInstance(context, shopId)in both plugins would make sense to me because looking up the API key always comes right before getting the instance. And passing in the plugin name from payment (paymentMethod.paymentPluginName) is actually not correct since it could theoretically change and we'd always want to use the current name for lookup. Instead it should be from a constant.
Thanks for cleaning up this code while doing this.
Signed-off-by: Alex Rattray <[email protected]>
β¦m in many places Signed-off-by: Alex Rattray <[email protected]>
Signed-off-by: Alex Rattray <[email protected]>
0839533 to
101ccef
Compare
|
Gotcha, thanks @aldeed ! The context around the future of the I like the idea of combining them as you outlined, and the context around Thoughts? |
|
@rattrayalex-stripe People not running marketplace should never have You can safely make the |
|
Gotcha! I think I'd rather do the plugin/package name change in the next PR as well then, if that's okay, since it'll be touching the same code. How does the rest of this PR look to you? I see a build failure from snyk, not sure what that means? |
|
I switched the base to For future PRs be sure to branch from and direct PRs to |
|
By the way, your contribution guide was super helpful and clear - it looks like the use of a |
Resolves reactioncommerce/reaction-feature-requests#57
Impact: minor
Type: feature
Issue
reactioncommerce/reaction-feature-requests#57
Solution
I hardcode the name
"ReactionCommerce"in a few places, which isn't great - do you have a suggestion for a place to reference that as a constant?Otherwise, I pull version and url from
package.json, which seems to be what reaction does elsewhere as well.Breaking changes
none.
Testing
none; do you have suggestions? I could write a nock test and copy/paste it in 5 places, but that doesn't feel great. I could also add a unit test for
getStripeInstanceForShopor add a case to an existing test file, such asstripeCapturePayment.test.js.