Skip to content
This repository was archived by the owner on Mar 27, 2021. It is now read-only.

Add the PaymentRequestButtonElement#100

Merged
cweiss-stripe merged 3 commits intomasterfrom
cw-pr
Oct 5, 2017
Merged

Add the PaymentRequestButtonElement#100
cweiss-stripe merged 3 commits intomasterfrom
cw-pr

Conversation

@cweiss-stripe
Copy link
Copy Markdown
Contributor

This PR adds the PaymentRequestButtonElement (+tests, +demo, +docs)

@cweiss-stripe cweiss-stripe requested review from jez and michelle October 4, 2017 18:26
README.md Outdated
});

paymentRequest.on('token', ({complete, ...data}) => {
console.log('received Stripe token': data);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The token would be data.token, right? How about, Received customer information:

And maybe a separate log for the token?

README.md Outdated
});

paymentRequest.canMakePayment().then(result => {
this.setState({canMakePayment: result});
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

result is not a boolean -- let's do !!result

};
```

The props for the `PaymentRequestButtonElement` are:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

onFocus and onBlur are also available!

Should we make this type a union type of ElementProps and {paymentRequest: ...}?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could! It has no onChange prop, though.
The only reason I made this a separate component, instead of using the existing Element component, was to get more specific prop validation and types.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK, makes sense. Thinking about it more, maybe let's hold off on exposing more API surface area unless folks need it.

@michelle
Copy link
Copy Markdown
Collaborator

michelle commented Oct 4, 2017

Looks good generally; good set of tests! I think this Element shares more with the other Elements than we're exposing here, though.

ptal @cweiss-stripe

@michelle
Copy link
Copy Markdown
Collaborator

michelle commented Oct 5, 2017

lgtm!

Copy link
Copy Markdown
Collaborator

@jez jez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly just questions for my own understanding. Feel free to merge unless you feel strongly about making any of the suggested changes.

README.md Outdated

The [Payment Request Button](https://stripe.com/docs/elements/payment-request-button) lets you collect payment and address information from your customers using Apple Pay and the Payment Request API.

To use the `PaymentRequestButtonElement` you need to first create a [`PaymentRequest` Object](https://stripe.com/docs/stripe.js#the-payment-request-object). You can then conditionally render the `PaymentRequestButtonElement` based on the result of `paymentRequest.canMakePayment` and pass the `PaymentRequest` Object as a prop.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We downcase "object" (in PaymentRequest object and others) throughout our pages on https://stripe.com/docs.

In the longer term, I'm still bullish on moving the docs in this README into /docs for consistency.

this.context.unregisterElement(this._element);
}
props: Props;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something, but what did this get removed for? Seems like maybe we're not being as strict with types as we could be, but maybe we're making up for this somewhere else.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New Flow does not require Props to be declared this way. (See the class signature)

on: Function,
show: Function,
},
};
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine we're using Function here because that's how it was done in the old Element component. We could get more type safety using Flow's SyntheticEvent<T> types: https://flow.org/en/docs/react/events/. Not sure if this is important enough to block.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but the events are not DOM Events, but events from the wrapped Stripe Element component. We could still be more specific, though! I'll leave that for a separate PR.

},
};

const noop = () => {};
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, if we were using SyntheticEvent<T> for our props, I imagine Flow would catch that noop should take a single event argument, instead of "no" arguments.

@stripe-archive stripe-archive deleted a comment from jez Oct 5, 2017
@stripe-ci stripe-ci removed the approved label Oct 5, 2017
@cweiss-stripe cweiss-stripe merged commit 8741983 into master Oct 5, 2017
@jez jez deleted the cw-pr branch October 18, 2017 18:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants