[Stripe-v3] Allow Implicit Elements Resolution

[JakeCooper]

Stripe supports implicit elements resolution through createToken.

If only options are passed, it will attempt to resolve the element from Stripe.js.

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If adding a new definition:

• The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• Create it with dts-gen --dt, not by basing it on an existing project.
• Represents shape of module/library correctly
• tslint.json should be present and it shouldn't have any additional or disabling of rules. Just content as { "extends": "dtslint/dt.json" }. If for reason the some rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
• tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: <>
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

If removing a declaration:

• If a package was never on DefinitelyTyped, you don't need to do anything. (If you wrote a package and provided types, you don't need to register it with us.)
• Delete the package's directory.
• Add it to notNeededPackages.json.

[typescript-bot]

@JakeCooper Thank you for submitting this PR!

🔔 @ejsmith @amritk @AdamCmiel @jleider @galuszkak @slangeder @marlosin @ttmarek @kimehrenpohl @KrishnaPravin @hirochachacha - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#40470	diff
Batch compilation
Memory usage (MiB)	80.5	80.0	-0.6%
Type count	11317	11317	0%
Assignability cache size	34676	34676	0%
Language service
Samples taken	433	433	0%
Identifiers in tests	433	433	0%
getCompletionsAtPosition
Mean duration (ms)	365.9	365.3	-0.2%
Mean CV	9.6%	10.0%
Worst duration (ms)	474.7	468.6	-1.3%
Worst identifier	threeDSource	paymentMethod
getQuickInfoAtPosition
Mean duration (ms)	368.0	362.9	-1.4%
Mean CV	10.4%	10.3%	-0.9%
Worst duration (ms)	473.8	460.6	-2.8%
Worst identifier	id	style

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[KrishnaPravin]

@JakeCooper
stripe.createToken({ name: 'customer name' }).then((result) => console.log(result))
When I tried using this snippet, I got the error from Stripe saying "You must provide a Stripe Element or a valid token type to create a Token.".

I guess we need to pass at least any 1 element to the createToken method. eg: a CVV element can resolve other elements like card number, expiry, etc

[JakeCooper]

https://github.com/stripe/react-stripe-elements/blob/master/README.md#server-side-rendering-ssr

Did you try it with server side rendering? I'm running that exact code on a new project and it doesn't seem to error.

[typescript-bot]

After 5 days, no one has reviewed the PR 😞. A maintainer will be reviewing the PR in the next few days and will either merge it or request revisions. Thank you for your patience!

[KrishnaPravin]

https://github.com/stripe/react-stripe-elements/blob/master/README.md#server-side-rendering-ssr

Did you try it with server side rendering? I'm running that exact code on a new project and it doesn't seem to error.

If possible can you please send a small working snippet. So that I can run it.

[amcasey]

Sounds like we should hold off on merging until we hear back from @KrishnaPravin?

[KrishnaPravin]

Sounds like we should hold off on merging until we hear back from @KrishnaPravin?

If someone else can verify if Stripe supports implicit elements resolution through createToken without at least one stripe element you can definitely merge it.

It is just I'm not able to replicate from my side.

[amritk]

Isn't it about time stripe starts managing these themselves? Can we tag a stripe engineer?

[KrishnaPravin]

Isn't it about time stripe starts managing these themselves? Can we tag a stripe engineer?

It will definitely help. Please do it.

[orta]

They will be: stripe/stripe-node#736

Not sure what to do with this PR yet, so will hold off on merging.

[rattrayalex-stripe]

@orta that PR is for a different library than this one is; they're orthogonal.
However, I'll bump this PR to the relevant internal team...

[mbarrett-stripe]

Hi, I work on Stripe.js

I think there's been a bit of a misconception here. This version of createToken is available only in react-stripe-elements and is not a native capability of Stripe.js v3's createToken(). You can see the function being wrapped for React application convenience here

I'd recommend taking a look at the DefinitelyTyped defs for React-Stripe-Elements and seeing if that satisfies the need here, looks like it might.

[sandersn]

Sounds like this can be closed then.