Data Lackey
Tired of having to build promise chains to coordinate the loading of your pages?
Tired of having pages break because a user linked from a different page?
Tired of overloading your server with duplicate requests for the same data?
Give Data Lackey a spin....
Data Lackey orchestrates data loading for rich front-end JS applications.
With Data Lackey:
- declaratively express which data is needed by components
- automatically track which data is not loaded, being loaded and already loaded
- configure dependencies between data, and be guaranteed data is loaded before other data
- reload data at periodic intervals (poll)
- expire data / support a ttl (time to live) for individual pieces of data
Installation & Basic Usage
shell> yarn add data-lackey
You'll need create a "data lackey" to track your data loading. Creating a file for this:
import { DataLackey } from 'data-lackey'
export const myLackey = new DataLackey()
myLackey.rule('/books',
{
loader: () => fetch('/api/books')
})
myLackey.rule('/book :bookId',
{
loader: ({bookId}) => fetch(`/api/books/${bookId}`),
dependsOn: 'books'
})
And then, configure your component with a new wrapping method mapPropsToDataRsrcs
:
import { loadData } from 'data-lackey'
import MyComponent from './MyComponent.jsx'
const mapPropsToDataRsrcs = props => `/book ${this.props.id}`,
WrappedComponent = loadData(mapPropsToDataRsrcs)(MyComponent)
export default WrappedComponent
Now, when the component is mounted, the book
details will be requested. Since
that is dependent on the books
data as well, that will be loaded first.
Advanced Usage
Data Lackey works great with React, and removes tedious and error prone data loading
code, replacing it with declarations of data depedencies. Usage within React is 100% configuration driven and is outlined here.
You can also use it directly, to isolate the load orchestration details. This is called
"direct usage" and outlined here.
Testing with Data Lackey
Data Lackey itself is well tested. As most of the configuration of Data Lackey is declarative, there's
less of a need to test this configuration. Given that, though, loader
functions can be unit tested,
as any data loading function can be tested. They are conveniently isolated from any component code.
API
Terminology:
load
: queue up a data resource to loaddata resource
Data Resource states:
undefined
: unknown data resource, not yet trackedloading
loaded
=> action unload
failed to load
TODO
unload
callback should pass in params from matcher, not just URL- ttl
- Load in batches
- accept params to url. So a resource can be
{ uri:
/item, itemId: 7 }
that automatically becomes /item?itemId=7
. Needs URL encoding, sorting of params.
Related Projects