# @wranggle/storage-core

> Core package for WranggleStorage class

Latest version **0.2.4** (published 2019-03-22) · Apache-2.0 license · 0 weekly downloads

## Install

```sh
npm install @wranggle/storage-core
pnpm add @wranggle/storage-core
yarn add @wranggle/storage-core
bun add @wranggle/storage-core
```

## Health

**Score 30/100 (F)** — status: abandoned.

Positive: has types; esm support; no vulnerabilities; high quality score.

Warnings: low downloads; pre 1.0.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 0.2.4 |
| Published | 2019-03-22 |
| First published | 2019-03-19 |
| Weekly downloads | 0 |
| License | Apache-2.0 |
| TypeScript types | bundled |
| Module format | ESM + CommonJS |
| Node | >=8.0 |
| Dependencies | 0 |
| Unpacked size | 162.5 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | Jeff Ferber |
| Maintainers | wranggle.ferbs |
| Keywords | wranggle-storage, storage, persistence, middleware |

## Links

- npm: https://www.npmjs.com/package/@wranggle/storage-core
- Repository: https://github.com/wranggle/storage
- Issues: https://github.com/wranggle/storage/issues
- npm.io page: https://npm.io/package/@wranggle/storage-core

## Alternatives

- [@sindresorhus/slugify](https://npm.io/package/@sindresorhus/slugify.md) — 3.7M weekly downloads
- [solid-js](https://npm.io/package/solid-js.md) — 2.7M weekly downloads
- [expo-glass-effect](https://npm.io/package/expo-glass-effect.md) — 2.5M weekly downloads
- [nanoassert](https://npm.io/package/nanoassert.md) — 780.8K weekly downloads
- [@ffmpeg/ffmpeg](https://npm.io/package/@ffmpeg/ffmpeg.md) — 529.5K weekly downloads

## Recent versions

- 0.2.4 (latest) — 2019-03-22
- 0.2.3 — 2019-03-21
- 0.2.2 — 2019-03-19
- 0.2.1 — 2019-03-19

## README

# WranggleStorage Misc 

This `@wranggle/storage-core` package is responsible for the main `WranggleStorage` class, used to create an RPC endpoint.

Its main documentation is in the [topmost README](/wranggle/storage) of this monorepo. This rpc-storage README holds odds and ends that don't belong there.


## Subset Store

The `createSubsetStore` method lets you splinter off a new WranggleStorage instance from an existing one, inheriting all of the parent feature layers. You can then add new feature layers to the child that are not applied to the parent.

For example, you might set up a parent *sessionStore* to hold transient data, then apply different namespaces to child stores:
```
const sessionStore = myStore.createSubsetStore({ expire: oneDayInMs });
const thisProjectStore = sessionStore.createSubsetStore({ bucket: 'Project:01' }); 
const thatProjectStore = sessionStore.createSubsetStore({ bucket: 'Project:02' }); 
```
Both `thisProjectStore` and `thatProjectStore` share the expiring-keys behavior of its parent. The "bucket" option adds a [KeyNameLayer](https://github.com/wranggle/storage/tree/master/packages/storage-key-name-layer), creating separate namespaces for the child stores. 


## Manipulate Feature Layers

Normally you'll specify the feature layers needed when you construct your WranggleStorage instance. You can, however, add or remove features after construction.


The store instance contains an array of FeatureLayer instances that you can manipulate. `myStore.layers` is publicly accessible and can be manipulated directly. Your WranggleStorage instance includes a couple helper methods:

* **useFeatureLayer** constructs the feature layer instance if not already created, pushing the result to the end of the `layers` array.
  ```javascript
  myStore.useFeatureLayer({ bucket: 'Projects' }); // inserts at ndx 1, the second feature layer in the array
  ```

* **insertFeatureLayerAt** constructs the feature layer if necessary and inserts it at the specified position. Eg:
  ```javascript
  myStore.insertFeatureLayerAt(new MyCustomLayer(), 1); // inserts at ndx 1, the second feature layer in the array
  ```

As with any middleware, order can make a difference. Be careful sorting or repositioning your feature layers.

When a data method is called, each layer has an opportunity to modify the request, from leftmost layer to the rightmost (oldest layer to newest) and then can modify the response / result in the opposite order, from right to left (newest to oldest layer.)


## Custom Feature Layers

TODO:
* how it works
* example and links to src of existing ones
* can extend NoopFeatureLayer
* tip: attention to ctx.result (vs return value. easy to forget)
* registering construction shortcut


## Custom Persistence Adapter

TODO:
* how it works
* example and links 
* registering construction shortcut


## Static Methods 
 
* `WranggleStorage.knownPersistenceAdapterTypes(): string[]` *static method* returns array of known persistence adapter types. These can be used as shortcuts during construction. Eg, if "memory" is listed, you can use `new WranggleStorage({ memory: true })`

* `WranggleStorage.knownFeatureLayerTypes(): string[]` *static method* returns array of known feature layer types. These can be used as shortcuts during construction. Eg, if "bucket" is listed, you can use `new WranggleStorage({ bucket: 'myBucket' })`
 
* `WranggleStorage.registerPersistenceAdapter(adapterType: string, factory: (opts: any) => PersistenceAdapter)`. Register a factory function for building your custom persistence adapter. Once registered, the adapterType can be used as a shortcut when instantiating WranggleStorage.   

* `WranggleStorage.registerFeatureLayer(layerType: string, factory: (opts: any) => FeatureLayer)`. Register a factory function for building your custom feature layer. Once registered, the layerType can be used as a shortcut when instantiating WranggleStorage or calling `useFeatureLayer`.

---
_Source: https://npm.io/package/@wranggle/storage-core · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._