# paypal-example-components **Repository Path**: mirrors_paypal/paypal-example-components ## Basic Information - **Project Name**: paypal-example-components - **Description**: Example component module for a component for unified PayPal/Braintree web sdk - **Primary Language**: Unknown - **License**: Apache-2.0 - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2020-08-18 - **Last Updated**: 2026-03-21 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## PayPal/Braintree Example Component [![build status][build-badge]][build] [![code coverage][coverage-badge]][coverage] [![npm version][version-badge]][package] [![apache license][license-badge]][license] [build-badge]: https://img.shields.io/github/actions/workflow/status/paypal/paypal-example-components/main.yml?branch=main&logo=github&style=flat-square [build]: https://github.com/paypal/paypal-example-components/actions?query=workflow%3Abuild [coverage-badge]: https://img.shields.io/codecov/c/github/paypal/paypal-example-components.svg?style=flat-square [coverage]: https://codecov.io/github/paypal/paypal-example-components/ [version-badge]: https://img.shields.io/npm/v/@paypal/example-components.svg?style=flat-square [package]: https://www.npmjs.com/package/@paypal/example-components [license-badge]: https://img.shields.io/npm/l/@paypal/example-components.svg?style=flat-square [license]: https://github.com/paypal/paypal-example-components/blob/main/LICENSE Example standalone component to be included in unified PayPal/Braintree client SDK ### Quick start See [src/index.js](./src/index.js) #### Tests - Run the tests: ```bash npm test ``` #### Testing with different/multiple browsers ```bash 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 ```bash npm run karma -- --browser=Chrome --keep-open ``` #### Releasing and Publishing - Publish your code with a patch version: ```bash 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. ```javascript export let LebowskiPay = { render(options) { ... } }; ``` Then the integrating site can run: ```javascript paypal.LebowskiPay.render({ ... }); ``` #### `/__sdk__.js` `__sdk__.js` defines any metadata which helps the sdk server compile and serve up the component. ```javascript 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: ```javascript 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.