That makes sense to me.



Given that, if I was using tx-listen, is it best to just switch over to 
add-watch on the root atom itself and serialize changes to the server from that?

On Wed, Oct 22, 2014 at 2:35 PM, David Nolen <[email protected]>
wrote:

> Expected for now. I'm beginning to rethink the role of :tx-listen -
> it's perhaps more useful as a simple pattern that we describe rather
> than an official part of the API.
> In anycase, I'd like to push ref cursors a bit further and see how
> people use ref cursors in their experiments before making any
> decisions.
> David
> On Wed, Oct 22, 2014 at 9:42 PM, Todd Berman <[email protected]> wrote:
>> I have been experimenting with reference cursors (which are great!), however 
>> I am running into a weird issue.
>>
>> It appears that changes made to a ref-cursor don't cause tx-listen to fire.
>>
>> Is that expected?
>>
>> --Todd
>>
>> On Saturday, October 18, 2014 10:52:06 PM UTC-7, David Nolen wrote:
>>> The parent view doesn't depend on items - that is, it does not need to
>>> re-render if items changes.
>>>
>>> David
>>>
>>> On Sun, Oct 19, 2014 at 1:38 AM, Jonas Enlund <[email protected]> 
>>> wrote:
>>> > Hi
>>> >
>>> > Interesting work as usual! One quick question: What is the difference 
>>> > between
>>> >
>>> >     (let [xs (om/observe owner (items))]
>>> >       ...)
>>> >
>>> > as seen in the sub-view component versus the one in main-view which 
>>> > doesn't use `om/observe`:
>>> >
>>> >     (let [xs (items)]
>>> >        ...)
>>> >
>>> >
>>> > /Jonas
>>> >
>>> >
>>> > On Saturday, October 18, 2014 6:53:50 PM UTC+3, David Nolen wrote:
>>> >> I'm happy to announce the release of Om 0.8.0-alpha1. This release
>>> >>
>>> >> includes the single biggest conceptual enhancement since its initial
>>> >>
>>> >> release - Reference Cursors.
>>> >>
>>> >>
>>> >>
>>> >> As we begin to build larger and larger applications with Om, we
>>> >>
>>> >> often run afoul of the need to organize our application around a
>>> >>
>>> >> hierarchical tree. This is more problematic than in React itself as Om
>>> >>
>>> >> emphasizes a programming model that supports full snapshotting of the
>>> >>
>>> >> application state. This seemingly beneficial property actually
>>> >>
>>> >> exacerbates the hierachical issue and often leads to an incredible
>>> >>
>>> >> amount non-modular programming!
>>> >>
>>> >>
>>> >>
>>> >> The introduction of Reference Cursors allow Om programmers to stop
>>> >>
>>> >> thinking in terms of trees and return to a more natural mode of UI
>>> >>
>>> >> programming - simply calling out into shared APIs around application
>>> >>
>>> >> data precisely where you need it. No need to pass data through
>>> >>
>>> >> intermediate components on way to the target child component -
>>> >>
>>> >> Reference Cursors allow you to get at the data exactly where it is
>>> >>
>>> >> required and this without abandoning the ability to time travel over
>>> >>
>>> >> your application state.
>>> >>
>>> >>
>>> >>
>>> >> There are more thoughts and details here:
>>> >>
>>> >> https://github.com/swannodette/om/wiki/Advanced-Tutorial#reference-cursors
>>> >>
>>> >>
>>> >>
>>> >> Please give Reference Cursors a try in your application and send lots
>>> >>
>>> >> of feedback!
>>> >>
>>> >>
>>> >>
>>> >> This is an alpha release. No previous Om APIs should be affected,
>>> >>
>>> >> however the Reference Cursor feature is largely untested beyond
>>> >>
>>> >> a simple example in the repo.
>>> >>
>>> >>
>>> >>
>>> >> https://github.com/swannodette/om
>>> >>
>>> >>
>>> >>
>>> >> Cheers,
>>> >>
>>> >> David
>>> >
>>> > --
>>> > Note that posts from new members are moderated - please be patient with 
>>> > your first post.
>>> > ---
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "ClojureScript" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an 
>>> > email to [email protected].
>>> > To post to this group, send email to [email protected].
>>> > Visit this group at http://groups.google.com/group/clojurescript.
>>
>> --
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/clojurescript.
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "ClojureScript" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojurescript/I8-kYj-eKBs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to