web-client repository infrastructure about paypal-sdk-client

[bluepnume]

I'm not against this, but just want to point out that in bt.js we made the conscious choice to not use a transpiler to avoid bugs/unintentional behavior introduced by the transpiler.

Rationale makes a lot of sense 👍also need to balance it against the likelihood of engineers accidentally pushing ES6 code which "works in chrome™" but breaks in older browsers. Also, at this point, checkout.js is fully all-in on babel transpilation, so it would be tricky to back that out at this point.

One line we haven't crossed though (and have no plans to cross) is adding any kind of polyfills, which obviously have the potential to mess with merchant pages.

should also check against other common build tools and server side rendering

Anything works for me so long as

a) we can run it programmatically on the server side
b) it supports lazy import() statements so we can do lazy loading
c) we can define build-time variables which can be used for feature flags

We've had very good experiences with webpack for all of the above so far.

Just a note that I think it's more conventional in JS projects to use lowercase kebab case in file paths, IE hosted-fields not HostedFields. I don't feel strongly about this though.

Agreed on that.

[bluepnume]

All sounds good!

Few notes:

• Next thing for me to do in this module is flesh out some tests, right now karma is just stubbed
• Would prefer to not encode any specific knowledge of components like HostedFields directly in this module, since with the current design those components would depend on this client module.

[quinnjn]

We would have to build the module wrapper pieces like this: https://github.com/paypal/paypal-braintree-web-client#as-a-module-owner

Thats what I was thinking of when I wrote: src/component/HostedFields/index.js

[bluepnume]

Sure -- but the idea is, that attach() call would happen in the hosted fields module itself -- not in this module. So hosted fields can receive the options passed to the client, and decide which interfaces it wants to export.

Example of the same thing happening in the checkout.js module: https://github.com/paypal/paypal-checkout/blob/master/src/interface.js#L40-L52

• Component X does import { attach } from 'paypal-braintree-web-client/src';
• Component X calls attach(), gets a copy of any shared config, client options, etc.
• Component X returns its public interface, e.g. attach(() => { return { ComponentX: ... }; })
• paypal-braintree-web-client sets up public paypal.client() factory which is called by end-developer, e.g. let client = paypal.client({ env: 'production' })
• Anything returned during attach() is attached to that client, e.g. client.ComponentX.render()

So each component pulls in the client and decides what it wants to export -- but the client itself has little to no knowledge of which modules are going to use it. That way we don't have to code any component-specific use cases into this client -- it stays agnostic of whatever components are going to use it.

[crookedneighbor]

Just a few thoughts:

• Babel Transpiling | Uses flow

I'm not against this, but just want to point out that in bt.js we made the conscious choice to not use a transpiler to avoid bugs/unintentional behavior introduced by the transpiler.

• Builds to webpack

💯 <- should also check against other common build tools and server side rendering

• I could see the structure being:

Just a note that I think it's more conventional in JS projects to use lowercase kebab case in file paths, IE hosted-fields not HostedFields. I don't feel strongly about this though.

[demerino]

👍Makes sense to me.

So each component pulls in the client and decides what it wants to export -- but the client itself has little to no knowledge of which modules are going to use it.

This sounds pretty important. I think I've shared this before, but I'll share it once more as an example of the iOS approach which has worked well so far.

1. The iOS client has a service(s) that allow various modules to register. See BTTokenizationService.
2. Modules (Venmo, PayPal, iDEAL, ApplePay, etc...) register on load (if they are included at runtime). See BTVenmoDriver.
3. Finally, the end service (Drop-in or Smart Buttons) doesn't need to know about BTVenmoDriver or BTPayPalDriver. It just checks the tokenization service using strings and will kickoff the various flows if they are supported at runtime. See Venmo in Drop-in.

If what you're striving for is similar, then no knowledge is something I would strongly urge 🤔

[skunkworks]

Keeping mind that I don't have much context on how likely transpiler bugs are in babel, I'll say that I've had minimal to no issues developing in JS and running into issues with dynamic types. Perhaps this is because we do a lot of TDD and are implicitly verifying types?

I'm OK with the idea of adding type annotations to our code and having babel/flow in our toolchain. I don't think it's a big productivity or code quality gain from what Braintree does with our current tools, but it seems pragmatic for checkout.js considerations.

[bluepnume]

@demerino on the "zero knowledge" front, right now that's true for the client (the client has no knowledge of the individual components). The question of how much knowledge those specific components have about payment methods (be it spb or drop-in) is probably out of scope for the current effort, but I agree in principle that they should be as agnostic as possible to whatever they're surfacing. 👍

@skunkworks makes sense. Static types don't need to replace TDD, they just (partially) negate the need for tests which test for things like NPEs, the presence of public methods, etc.

[crookedneighbor]

For assuring that no es6 code gets pushed to production, we use a module that Evan Hahn and I put together: https://www.npmjs.com/package/check-ecmascript-version-compatibility

We then run this test file against the built files to make sure they only use es5: https://github.com/braintree/braintree-web/blob/master/test/environment/ecmascript-version.js