EditCardDetails: Refactor to a functional component #35237
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~22 bytes removed 📉 [gzipped]) Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
2 tasks
yoavf
approved these changes
Aug 11, 2019
getdave
pushed a commit
that referenced
this pull request
Aug 13, 2019
sirbrillig
added a commit
that referenced
this pull request
Aug 13, 2019
In preparation to upgrade the `AddCardDetails` component to use Stripe Elements and Payment Intents (see previous work in #34848), this PR just reorganizes the component into a stateless functional component instead of a class. Previously this was done for `EditCardDetails` in #35237 which is nearly identical to this component. There wasn't much present that required a class in the first place; there was no state, and I think the redirect-on-invalid behavior is actually easier to understand happening on every render than using the lifecycle methods.
sirbrillig
added a commit
that referenced
this pull request
Aug 14, 2019
* AddCardDetails: Refactor as functional component In preparation to upgrade the `AddCardDetails` component to use Stripe Elements and Payment Intents (see previous work in #34848), this PR just reorganizes the component into a stateless functional component instead of a class. Previously this was done for `EditCardDetails` in #35237 which is nearly identical to this component. There wasn't much present that required a class in the first place; there was no state, and I think the redirect-on-invalid behavior is actually easier to understand happening on every render than using the lifecycle methods. * Fix big errors How did I miss these? Clearly I wasn't paying attention.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes proposed in this Pull Request
In preparation to upgrade the
EditCardDetailscomponent to use Stripe Elements and Payment Intents (see previous work in #34848), this PR just reorganizes the component into a stateless functional component instead of a class.There wasn't much present that required a class in the first place; there was no state, and I think the redirect-on-invalid behavior is actually easier to understand happening on every render than using the lifecycle methods.
Testing instructions
4242424242424242) and submit the form. It will help to use a unique name for the cardholder name.