https://github.com/paypal/paypal-example-components
Example component module for a component for unified PayPal/Braintree web sdk
https://github.com/paypal/paypal-example-components
Last synced: about 1 year ago
JSON representation
Example component module for a component for unified PayPal/Braintree web sdk
- Host: GitHub
- URL: https://github.com/paypal/paypal-example-components
- Owner: paypal
- License: apache-2.0
- Created: 2018-03-07T00:34:11.000Z (over 8 years ago)
- Default Branch: main
- Last Pushed: 2023-11-23T19:36:19.000Z (over 2 years ago)
- Last Synced: 2024-10-29T18:08:32.347Z (over 1 year ago)
- Language: JavaScript
- Size: 72.3 KB
- Stars: 10
- Watchers: 21
- Forks: 30
- Open Issues: 12
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
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.