search

braintree / credit-card-type

A library for determining credit card type
MIT License
980 stars 154 forks source link

Added getCard(cardType) and export card type constants #23

Closed Benjamin-Dobell closed 8 years ago

Benjamin-Dobell commented 8 years ago

Firstly, I apologise for large size of the pull request (relative to the size of the project).

Nonetheless, I've added what I suppose most will think is some really useful functionality.

In particular a new exported function:

getCard(cardType)

This allows users to query data about known (typically persisted) card types, for which the card number itself may no longer available.

This is common in the sense that 99.9% of applications shouldn't actually be storing credit card numbers; that should be left to CC processing experts (BrainTree :wink: etc.) However, storing the last 3-4 digits of a credit card numbers, along with the credit card type, is pretty standard practice as a way to help card owners distinguish between their cards when they have several on file.

Combing this persisted information in conjunction with new getCard function allows one to put together UIs like:

card card2

For convenience, I've also exported card type constants. This means less string literals floating around in the code of consumers of this module.

Changes

I've renamed getCardTypes to matchCards in the documentation (well, and in code).

Originally I attempted to avoid this, but following the existing naming scheme led to my function being called getCardType(type) - which was very awkward fetching a "card type" by providing card type!

Realistically getCardTypes was never returning a "card type" as such, instead it returns one or more objects with info matching the specified card number - included in that info is the card type, but also some other great information.

Although I've renamed this function, due to this function being the "default export", the change is actually 100% backward compatible. So users of the module can upgrade and continue using getCardTypes within their own code (if that's the name they had previously chosen to use).

I've updated the README to document the new function and the exposed constants. I've also added a new section called "Advanced Usage" which highlights some use cases for the new functionality.

Benjamin-Dobell commented 8 years ago

Sorry, I have just forced pushed some cosmetic changes to appease the linter.

mrak commented 8 years ago

It looks like all you want as a feature is getCard?

mrak commented 8 years ago

This has been merged and released as of version 4.1.0.

We named your getCard function getTypeInfo. We took this in a separate branch and merge to master since we wanted to take care of compiling regular expressions in a loop while we were at it.

Thank you for the contribution and feature!