On Fri, Jan 24, 2014 at 2:44 PM, kovas boguta wrote:
> On Fri, Jan 24, 2014 at 10:29 AM, David Nolen
> wrote:
> > a) cursor can always be read directly during the render phase
>
> What does that look like exactly? No more om/value? Or by "directly",
> you mean via re-walking the path from the roo
On Fri, Jan 24, 2014 at 10:29 AM, David Nolen wrote:
> a) cursor can always be read directly during the render phase
What does that look like exactly? No more om/value? Or by "directly",
you mean via re-walking the path from the root?
> b) outside the render phase you can only update the applica
Ok I agree that om.core/read is a bear now that I'm working on the Om
tutorial.
Here's are my current thoughts for 0.3.0:
a) cursor can always be read directly during the render phase
b) outside the render phase you can only update the application state or
`cljs.core/deref` cursors and you will g
I second this request.
It took a little bit of re-thinking (perhaps because I'm still getting my head
into this functional thing :D ).
I tend to want to do stuff like this :
(some-fn (om/read cursor :a) (om/read cursor :b))
but of course, I really need to do something like this
(om/read cur
I see. I'll consider relaxing om.core/read to return data instead of
another cursor. This should make it easier to work with and you can always
hold onto the original cursor for doing app state transactions.
On Mon, Jan 20, 2014 at 6:46 PM, kovas boguta wrote:
> On Mon, Jan 20, 2014 at 5:36 PM,
On Mon, Jan 20, 2014 at 5:36 PM, David Nolen wrote:
Ok this sounds like an interesting problem :)
> Om attempts to address consistency issues. Just because you have a cursor
> doesn't mean you actually have the most current value in the application
> state, thus read. read is always guaranteed t
On Mon, Jan 20, 2014 at 6:20 PM, kovas boguta wrote:
> I'm having a hard time using read.
>
> I find myself using it in 2 places:
>
> 1. Inside the event handler, I want to read, optionally do something
> with the value (typically assoc/dissoc), and put it on a channel.
>
> 2. Inside a go block in
I'm having a hard time using read.
I find myself using it in 2 places:
1. Inside the event handler, I want to read, optionally do something
with the value (typically assoc/dissoc), and put it on a channel.
2. Inside a go block initialized during will-mount, same story.
The problem is that I do
