Don-Isdale
commented
6 years ago adding detail :
changes to data scope (e.g. add/delete map) : gui posts actions to mapview controller, which updates URL, for deletions, forwards the action via data-view listeners if there is requested data : for any requested data which is not in the store : sends requests for that data; promise resolution -> actions to data-view for requested data which is in the store : actions to data-view
for initial render, mapview route parses URL and requests data promise resolution -> actions to data-view
This post is to discuss a design improvement to the data flow.
In adding maps to an existing graph without redrawing, the design was to localise store access in mapview, and deliver a stream of promises via dataReceived to draw-map. Observing an array of promises didn't interact well with the Ember run loop (at that time), so fallback cases were added to draw-map to get data which wasn't received. The aim is to re-organise the location of parts of the data flow to achieve a simpler and more maintainable design.
outline of data flow :
gui : button clicks etc request additional chr-s (i.e. blocks) or zoom change / additional layers within an already-displayed chr -> actions, received by mapview mapview route: update URLs and issue requests, e.g. findRecord() -> promises, whose resolution -> -> actions deliver data streams to components Model returned by mapview route is data-view, which is Evented, i.e. components can listen on it for the stream of data types they are interested in.
components register / listen for actions delivering data types which they display, e.g. map name list, chr interval, marker / gene data component also has a scope; it will display received data within that interval. ( e.g. scope of axis component : chr name, interval; if we split an adjacency component out of draw-map, its scope would be the compound of the 2 adjacent axes). different components may display the same data in different ways.
routes normally map a single URL to 1 model; here the URL maps to a variety of async data
mapping requested changes, e.g. add/delete a map:chr to URL changes can be done by mapview controller mapview route will request any additional data required to fullfil the URL; data from resolving promises is added to the data-view, and actions deliver new data to listeners.
model is a subset of the store, a view in the db sense, hence the name data-view.
Other possibilities considered for model instead of Evented : promises (possibly already resolved) or iterator (generator .next() will return current(), or wait until promise resolves). Evented seems better, noting that promises return a single result, whereas the graph display components are listening for a series of data.
if multiple results arrive during a render, then next render should show all those, not just wait on 1 promise and display its result.
model result type is data-view, which is Evented; can have sub-views e.g. block (chr), adjacency (block x block), interval (block, range), marker set (marker names). That isolates the first-pass and most common filtering in data-view; performance is probably similar to the component receiving all actions and doing the filtering itself. This also minimises the action activity between components.
This design is a pipeline of relatively independent components, avoids centralising control which can lead to a monolithic design.