Recline JS - Componentization and a Smaller Core
Over time Recline JS has grown. In particular, since the first public announce of Recline last summer we’ve had several people producing new backends and views (e.g. backends for Couch, a view for d3, a map view based on Ordnance Survey’s tiles etc etc).
As I wrote to the labs list recently, continually adding these to core Recline runs the risk of bloat. Instead, we think it’s better to keep the core lean and move more of these “extensions” out of core with a clear listing and curation process - the design of Recline means that new backends and views can extend the core easily and without any complex dependencies.
This approach is useful in other ways. For example, Recline backends are designed to support standalone use as well as use with Recline core (they have no dependency on any other part of Recline - including core) but this is not very obvious as it stands (where the backend is bundled with Recline). To take a concrete example, the Google Docs backend is a useful wrapper for the Google Spreadsheets API in its own right. While this is already true, when this code is in the main Recline repository it isn’t very obvious but having the repo split out with its own README would make this much clearer.
So the plan is …
- Announce this approach of a leaner core and more “Extensions”
- Link to the specifications for Backends and Views
- Create an official Recline Extensions page
- Identify first items to split out from core - see this issue
- Identify what components should remain in core? (I’m thinking Dataset + Memory DataStore plus one Grid, Graph and Map)
So far I’ve already started the process of factoring out some backends (and soon views) into standalone repos, e.g. here’s GDocs:
https://github.com/okfn/recline.backend.gdocs
Any thoughts very welcome and if you already have Recline extensions lurking in your repos please add them to the wiki page
We make tools, apps and insights using
open stuff
Comments