raisely / restie Goto Github PK

The recent addition of promise cache/chaining allows a hook-like syntax, similar to https://github.com/zeit/swr. This should be documented, and if needed, a default hook added to Restie.

When an entity or set of entities is returned (flagged by presence of options.dataKey), an opt in should be provided that will wrap the returned entity based on it's unique key.

Considerations should be taken so that:

• A nested model can switch to ammend a new set of unique keys to allow a Restie model t be created with a new key
• A upper-level key (i.e uuid) should always be tried first.

A returned entity can (and should) represent the same nesting as a model.one(uniqueKey)

Implement basic CRUD testing environment with CI integration (coming soon)

• Can it send requests
• Can it accept JSON/text as expected
• Can it create models/nested models
• Graceful failure tests
• Do overrides work as expected

Adding typedefs will help ensure stability of instance passing and configurations.

Also add documentation to https://developers.raisely.com

Should utilise existing object-path-immutable and follow basic set and delete options when saving.

TBA

Inform users of how non FOSS-compliant licensing can be used as a library (verses a forward facing project license).

Once a unique keying system is added (likely it's own extension), it will be possible to detect when a specific key on a specific rest model has been requested multiple times - and to defer sending another request until the initial duplicate has resolved.

In most cases (where allowed) this will mean recycling the same Promise object used to commit the first request.