Introduction
ONE #
One
is a browser side application cache. It guarantees entity uniqueness across the entire cache.
Each entity tracked for uniqueness must have a unique id. There is precisely ONE distinct entity in the cache for each unique id. Entities that do not have a unique id are still cached but not tracked for uniqueness.
Usage
Or simply put one.min.js
on your page to access the One
global variable from anywhere. In this case the instance is created for you and you can access it directly (no need to call getCache()
).
A word about javascript versions compatibility
ES6 introduced Maps which are supposed to be up to 3 times more efficient than using Object for storing and retrieving keyed items. One
uses Maps by default. However for older browsers that do not support the standard you will need to compile the library with the babel-polyfill. The caveat is that it bumps up the size of the minified lib from ~16kb go ~100kb.
To compile with polyfill:
Uncomment this line in index.js
```
!javascript
//import 'babel-polyfill';
!javascript
npm run prepub
Immutable
All data is immutable. Once an item enters the cache it freezes and cannot change. This is to enable quick identity checks against immutable entities (ie React identity check).
If you later want to edit a reference of the object you can get an editable copy from the cache. This gives you a separate clone of the object that is now editable:
Editing an item changes all its instances in the cache:
Motivation
More an more applications are giving users the ability to edit data in the browser. With a normalized data model various instances of an entity can exist at the same time in different locations. This depends on how data is received from the server and added to the local model / store.
This is inconvenient because:
Keeping all the instances in sync can be a daunting task.
It can make debugging hard.
It requires tracking each instance and makes reasoning about data complicated.
It can make the application structure needlessly complex.
Redux brings a great breakthrough by putting the entire application state in one place and mutating it only via dispatched actions. But it doesn't enforce entity uniqueness. One
aims to take the concept a step further by making each entity unique and immutable in a single store (cache).
Performance considerations
Yes there is a performance cost in analyzing each entity deeply to track its dependencies. One
offers a couple of ways to mitigate this: Read optimization and Queuing.
Read optimized: the penalty is incurred on write operations only. These happen a lot less frequently than read ops. Read ops are super fast (a simple key lookup).
Queuing allows the developer to choose when to perform the write operation.
One
defers the write analysis when writing to the queue. The queue can commit between render operations. This way the UI remains fluid.If you were to track all instances of an entity on each update the write penalty could end up being comparably high. This is besides the added complexity introduced by such tracking management.
Data shape
This is not currently designed to work with cyclical data. It is best for non-cyclical objects received from the server in the form of json (or other non-cyclical fomats). It might happen later if there's a need.
Documentation
Last updated