ducky/web

• Commits
• Files

2:b9d0efb44eaa Go to Latest

ducky/web/src/pages/payment.jsx

Validate registration, add payment page. Add lodash.debounce to debounce our validation. Update react-ladda to take advantage of the bugfix that will make it disable the button properly. Use react-script-loader to load stripe.js for our payment page async. No, I'm not terrified that I'm planning on shipping the mission-critical version of my software (the part where I get _paid_) using v0.0.1 software. Should I be? Add jwt-decode so we can decode the access tokens we get in response. We can't _verify_ them, but since we're not a source of truth, that really doesn't make much a difference. Everything is considered to be tamperable, anyways, so we never rely on the client being authoritative or safe. Add a `npm run deploy` task that will deploy the damn project to surge. Create a ValidationError component that will look through a set of errors for the ones that apply to it, and display the appropriate message for them. Update our config.js with a new (bullshit) clientID and clientSecret. It would help if we used an actual database to store these instead of storing them in memory, so I didn't have to generate them fresh every time. But then I'd have to delete accounts, too. Where's the fun in that? We also added a stripeKey which is the publishable key for our test account. Suck it, scraper bots. Use jwt-decode to decode the access token we receive into a claim we can pull the ProfileID out of. The Me model gains a profileID attribute to store this new information, so we can tell who the eff is signed in. We also used the ever wonderful derived properties feature to make a me.profile, which will always resolve to the profile of the signed in user, as it exists (stored locally). We should probably do some fallback checking to make it fetch the profile from the server, huh? I'll open an issue. Create our payment page. this is scary similar to our registration page, except we're loading stripe.js async (and disabling the buttons until it's loaded), and we're asking for the credit card details, instead of their email and password. We then trade the credit card details for a token (hooray, no need to deal with PCI compliance!) and we'll eventually send that token to our server, to create a customer. Taking money is complicated. Hilariously, we have the code to turn all the Stripe server errors into errors our ValidationError component can handle, and we have the ValidationError components placed, but we haven't defined the error messages for them yet. Oops. We also haven't done any kind of local validation. Oopsie. We used our ValidationError to set up errors for our register page, and also used the debounced validator to check the information while we type. What's not to love? Haven't quite gotten around to handling server errors yet. It's on the to-do list. Also, how hilarious is it that we need three freaking methods to debounce our validation properly? Once we register a profile, we should continue on to the payment method part of the program, so we tossed that router.navigate call in there. Finally, we updated our IDs, because reasons and typing. We also included a new _flashes.scss page that will take care of our error display, and added payment page styles to our onboarding.scss file. Finally, we updated our webpack config to output all the files to build/static so we can use build/ as our deploy folder, with an index.html in the root of it.