Aaron Craelius

Well, the benefit of having observable collections exposed to the user is that it removes the need to do diffing when the collection is updated because you can track changes...

Regarding custom namespaced plugins, it's pretty simple. When freactive gets a tag it does something like: ``` clj (let [tag-ns (namespace tag) tag-name (name tag)] (if tag-ns .... ....)) ```...

Also, because `freactive.dom/bind-attr*` is pretty generic it can be the basis for binding attributes to custom "nodes" such as the `items-view` for instance - thus bindable sorting, filtering, etc.

Okay so the most important thing right now is deciding on the right `IObservableCollection` API - this is the common thing that will be shared between any potential observable collection...

Hey Tim, so I'm not sure I understand the scenario you're describing in **A)** and **B)** but what I can say is that freactive observable collections would be able to...

Your sub-item will be generated by the `:template` parameter which takes a `(fn [cursor-to-item])` which should return a view for that item (see: https://gist.github.com/aaronc/5d497aa61e27ce924178). You could bind an `:on-click` handler...

So, my current design is to have the `items-view` function simply return a DOM node for the entire items view. freactive allows DOM nodes to be passed directly in as...

Well `:container` will be something like `[:div]` although I guess you could theoretically pass in a DOM element that you retrieved by ID. `:container` will be passed to `build-dom-element` (https://github.com/aaronc/freactive/blob/develop/src-cljs/freactive/dom.cljs#L884-L910)...

Okay, so I think these are two separate things. You don't need an items view at all for the details view if I understand what you are trying to do...

`:template` provides the view for each item in a sequence (list view), not for the detail view. Take this for example: ``` clj [:ul (for [i [0 1 2 3]]...