PayPal/Braintree Example Component

Example standalone component to be included in unified PayPal/Braintree client SDK

Quick start

See src/index.js

Tests

• Run the tests:

  npm test

Testing with different/multiple browsers

npm run karma -- --browser=Chrome
npm run karma -- --browser=Safari
npm run karma -- --browser=Firefox
npm run karma -- --browser=Chrome,Safari,Firefox

Keeping the browser open after tests

npm run karma -- --browser=Chrome --keep-open

Releasing and Publishing

• Publish your code with a patch version:

npm run release

• Or npm run release:patch, npm run release:minor, npm run release:major

Module structure

• /src - any code which should be transpiled, published, and end up in production
• /test - karma tests for everything in /src
• __sdk__.js - metadata for compiling and bundling the final component

/src/component.js

This module exports the public interface for the component.

export let LebowskiPay = {
    render(options) {
        ...
    }
};

Then the integrating site can run:

paypal.LebowskiPay.render({ ... });

/__sdk__.js

__sdk__.js defines any metadata which helps the sdk server compile and serve up the component.

export default {
  /**
   * Define the lebowski-pay component
   * Now developers can include paypal.com/sdk/js?components=lebowski-pay
   */

  "lebowski-pay": {
    /**
     * Entry point. Everything exported from this module will be exported
     * in the `window.paypal` namespace.
     */

    entry: "./src/index",
  },
};

FAQ

• Why is there no webpack config, dist folder, or npm build command?

  This module (and modules like it) are not intended to be built as standalone components. It will be pulled in and compiled/bundled on the server-side, then combined with other modules.

• When should I publish?

  When you publish, you're signing off on your changes being code-complete, fully tested, and ready for release. Publishing will not immediately trigger a deploy, but please only publish changes which are in a deployable state.

• Can I define multiple components in one repo?

  Absolutely. __sdk__.js allows defining multiple entry points. These should generally represent different logical ui components, with separate concerns, and loose coupling. For example:

  modules: {
    'lebowski-pay': {
        entry: './src/components/lebowski-pay'
    },
    'walter-pay': {
        entry: './src/components/walter-pay'
    },
    'donnie-pay': {
        entry: './src/components/donnie-pay'
    }
  },

  Please bear in mind that this opens the door to any combination or permutation of these modules to be requested by the merchant -- hence the need for loose coupling. donnie-pay should never have a hard dependency on lebowski-pay being present.

• Where is all of the karma, webpack, eslint, etc. config coming from?

  This module uses @krakenjs/grumbler-scripts as a common source of configuration and defaults. Any of these can be overriden, either partially, or entirely, depending on the individual needs of the module. You'll notice .eslintrc.js, karma.conf.js, etc. are lightweight wrappers which only define module-specific overrides.