potion-client
v3.2.1
Published
A ES6 client for APIs written in Flask-Potion
Downloads
128
Readme
Potion
A TypeScript client for APIs written in Flask-Potion.
Table of Contents
Installation
Install this package with NPM:
$(node bin)/npm install potion-client
Or Yarn:
yarn install potion-client
It can also be used with JSPM:
$(npm bin)/jspm install potion=npm:potion-client
Usage
Before you use this package, make sure you include reflect-metadata and a shim for ES6/7 features (core-js has the most comprehensive collection of shims and I advise using it).
Furthermore, this package has multiple implementations available, it can be used with:
- Fetch, using Fetch API (make sure to include a polyfill such as whatwg-fetch if you are targeting a browser that does not implement the API);
- Angular;
- AngularJS.
IMPORTANT: All resource properties that are retrieved from the backend will be converted from snake case to camel case, so the following:
class Foo(db.Model):
bar_name = db.Column(db.String(256), nullable=True)
Will match the following resource on the client side:
class Foo extends Item {
barName: string;
}
Contribute
If you'd like to contribute:
- Clone the repository
git clone https://github.com/biosustain/potion-node
; - Install all the deps
yarn install
/npm install
.
Now you can start hacking :)
Before you make a pull request, you can check if builds and tests will run successfully:
- Run the tests using
npm run test
(if you wish to run tests on file change, usenpm run test:continuous
); - Use
npm run build
to build the.ts
files and see if any errors have occurred.
If you're a contributor and you wish to publish the package, use the release scripts from package.json
.
For example, if you wish to publish a patch, use:
npm run release
NOTE: Do not forget to git push --follow-tags
when you push, otherwise tags might not be pushed (depending on your Git global config).
The master
branch will publish to the latest
tag, whereas the next
branch will publish to the next
tag on NPM.
This can be useful for making pre releases or major changes and allowing users to test the lib,
but not break apps depending on the latest version.
As a rule of thumb, you should always make a pre release only in the next
branch,
allowing for publishing the stable version from the master
branch:
# Make a patch pre release so that:
# 1.0.0 -> 1.0.1-0
# using:
npm run release:prerelease
# NOTE: Subsequent runs of the command above,
# will result in: 1.0.1-1, 1.0.1-2, etc.
# Make a major pre release so that:
# 1.0.0 -> 2.0.0-0
# using:
npm run release:premajor
# From there on,
# to increment the pre release version so that:
# 2.0.0-0 -> 2.0.0-1
# use:
npm run release:prerelease