`createPipe` better types

v6.2.3

chore(createPipe): better type inference

`createApi` better types

For when you provide a ctx in a function endpoint definition without props

createApi better types fix

Trying to allow end-user to override ctx in function definition of their endpoints if desired.

`createApi` better types

feat(createApi): better types

`createApi().[method]` has better type support for inferring `ctx`
properties.

```ts
import { createApi } from 'saga-query';

interface Props { id: string }
interface Success { result: string }
interface Err { message: string }

const api = createApi();

const fetchUser = api.get<Props, Success, Err>(
    '/users/:id',
    function*(ctx, next) {
        // will be set to `Props`
        ctx.payload;

        yield next();

        if (ctx.json.ok) {
            // will be set to `Success`
            ctx.json.data;
        } else {
            // will be set to `Err`
            ctx.json.data;
        }
    },
);

dispatch(fetchUser({ id: '1' }));
```

createApi endpoints support arrays for names

feat: support multiple endpoints with the same name (#27)

Previously the name provieded to `api.get('/the-name')` had to be unique.

Internally we used that name for a few internal maps that assumed they
would always be unique.

However, we want to support the ability for `createApi` to support
scenariors where you have the same name HTTP endpoint defined multiple
times.  Why would someone want that?  Because we have special sagas that
can be used to provide additional functionality to our endpoints -- like
polling -- we want to ensure they can use them without colliding with
more basic endpoints.

```ts
const api = createApi();
const action = api.get('/');
const pollAction = api.get('/', { saga: poll(5 * 1000) });

dispatch(pollAction());
dispatch(action());
```

Here we have a case where we want to duplicate
the name because it relates to the API endpoint we want to hit.

To fix this we now support the ability to provide an array for the name
of the endpoint.

```ts
const api = createApi();
const action = api.get('/');
const pollAction = api.get(['/', 'poller'], { saga: poll(5 * 1000) });

dispatch(pollAction());
dispatch(action());
```

The first part is the string used to generate the url with our
`urlParser` middleware.  The remaining parts are used for making the
name unique and are otherwise not used.

Although other middleware could be creative with using the array of
strings.

`useCache` now calls `useQuery`

This is a breaking change before useCache previously used useApi which meant that the end-user had to call useApi().trigger for the action to be dispatched. Now it is handled automatically.

We also added tsdocs to many of our public functions.

`customKey` middleware and new `createKey` algo

This releases adds a new middleware customKey which is loaded into the requestMonitor middleware. The benefit of this middleware is users can now override the auto-generated ctx.key inside their middleware:

const fetchUsers = api.create('/users', function*(ctx, next) {
  ctx.key = 'fetch-users-key';
  yield next();
})

ctx.key is used for automatic caching.

We also modified the algorithm for generating the key automatically. Instead of a base64 encoding we are now performing a hash (pulled from https://gist.github.com/iperelivskiy/4110988).

• #24 @VldMrgnn

export createKey and selectDataByName

Two new functions are exported:

• createKey which will create a key based on name and payload. This is the function we use to create ctx.key` which is what we use to set loaders as well as the key for caching data
• selectDataByName which is a selector to grab cache data by name and payload

revert esm build

v5.0.8

revert build system (#21)

send src to pkg

v5.0.7

send src/ to npm pacakge