Confirm
31
edits
Changes
→As a front-end developer, I need to be able to specifiy sub-sets of information and be notified when these sub-sets change, so that parts of the interface can react to the data that interests them.
''There are a few ways to do this. Event channels is one. Filtering is another. If you think about it, event channels are really a domain specific language around querying change notifications. I prefer a filtering approach because predicate functions are more flexible than DSLs. If we still should want an event channel DSL, we could create one on top of predicate functions.'' -[[Gbrander]]
''We have a simple-enough implementation borrowed from dojo's object store. Its query method accepts a dictionary of properties as predicate for the matching, and returns a lazy array of results. Furthermore, put/add/remove operations on the store trigger a check on these queries to determine if their results are impacted, and the change is sent to these resultsets via its observe mechanism. The query engine is pluggable - we can use a more sophisticated engine if necessary. The observe method on resultsets does not itself speak EventEmitter, but is easily wired into. There's an assumption baked into the design that reads are more frequent than writes - as each write essentially re-applies all open queries against the data.'' [[Sfoster]]
''The client-side store is there to provide convenient access to data and abstracts away details of where the data originally comes from. To this end, we decorate records with a <code>meta_type_</code><em>name</em><code>: true</code>, making queries for types as easy as <code>store.query({ meta_type_foo: true })</code>. Similarly, the composite nature of some responses is flattenned out - each object in s a response is filed separately'' [[Sfoster]]
==== As a front-end developer, I need to transform data coming from the server for display on the client-side. I need this transformed data to be "live". It should be updated when the original data is updated. ====
