potion-client

Potion

A TypeScript client for APIs written in Flask-Potion.

Table of Contents

• Installation
• Usage
  • API
  • Angular
  • AngularJS
  • Fetch
• Contribute

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:

1. Clone the repository git clone https://github.com/biosustain/potion-node;
2. 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:

1. Run the tests using npm run test (if you wish to run tests on file change, use npm run test:continuous);
2. 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 that 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, in the next branch, you should always make a pre release, allowing for publish the stable version in 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

Changelog

1.5.3 (2017-05-29)

<a name="1.5.3-1"></a>