React-stripe-elements: Removing `PostalCodeElement` was a mistake, and you should put it back

Created on 24 Aug 2019 · 5Comments · Source: stripe/react-stripe-elements

For completely undocumented reasons, PostalCodeElement was removed in v3.0.0 with no clear guidance other than 'implement your own'. After digging around for some time I found this comment from @dweedon-stripe: https://github.com/stripe/react-stripe-elements/issues/369#issuecomment-509119629

It's absurd to me that you completely removed an element that has been in production for a long, long time because there were apparently 'edge cases' in validation. I would wager that for the vast majority of users, the PostalCodeElement was more than good enough. Folks, you've thrown the baby out with the bath water.

Since Stripe's payment process encourages the collection of Postal codes to enhance the verification of a charge, you simply must and should provide an element that is capable of collecting that information out of the box.

Even if the PostalCodeElement has issues with limited edge cases, that shouldn't have warranted its complete removal over let's think... improved documentation around the edge cases? Renaming it BasicPostalCodeElement? Anything other than forcing me to dig back in this repos history to find the component and patch it into my project.

Source

johnmcdowall

👍25

Most helpful comment

+1 - it is very painful to duplicate the styling of the other elements in my custom postal code element.

davidvgalbraith on 11 Sep 2019

👍5

All 5 comments

+1 - it is very painful to duplicate the styling of the other elements in my custom postal code element.

davidvgalbraith on 11 Sep 2019

👍5

Has anyone succeeded in taking the code from an old version and made it work with the current version?

fredrik-hjarner on 24 Sep 2019

I have to agree. At least take it out of the demos on the documentation page. Currently, people peruse the demos just to find out later that it isn't part of the library. People are led under false pretense that this is a comprehensive off-the-shelf solution. Instead, people find out that they have inherited an edge case of their own: one that requires unnecessary work to commingle Stripe and custom fields side by side. The styling and validation of both can be a real pain and now that pain is spread far and wide.

No code is perfect and edge cases, particularly when it comes to something like payment processing, are just part of life. The baby with the bathwater metaphor most certainly applies. I liken it to selling a car without floor mats (because seemingly everyone can cut their own and besides the ones we could give you might not fit perfectly in all cases). Meanwhile, everyone is buying carpet and their own tools to make floor mats that would have been a straightforward, centralized task for the manufacturer.

What is wrong with a simplified component that implements the interface, defaults to accepting 10 characters--or something like that--and puts the onus of any problematic, context-specific validation on the developer?

I truly appreciate the library. This one thing baffles me, that's all...

babalugats76 on 12 Oct 2019

👍3

Yup, agree as well. I started on Stripe integration yesterday and used the fiddle here https://jsfiddle.net/attystripe/xux7qzch as the starting point, and couldn't figure out why the resulting error for a fiddle that's working:

_Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
Check the render method of CheckoutForm._

After trial and error I finally concluded that PostalCodeElement was the culprit and removed it.

I can see that the earlier fiddle has been replaced today with one (https://jsfiddle.net/mbarrett_stripe/6jLze147/) that no longer has PostalCodeElement.

Would have saved me a ton of time and headache if this was done just a day earlier :-D

zehawki on 26 Oct 2019

Hi all, thanks for bringing this up, I definitely feel your pain -- we've been discussing about the postal code situation a lot on our team recently, and have some ideas about how we can bring similar functionality back in the future without the validation issues mentioned.

Going to close this for now, as this project has migrated to React Stripe.js -- please follow along there and/or at StripeDev on twitter for upcoming news about new features/APIs.