On 3 Sep 2014 06:51, "Alan Shaw" wrote:
>
> PS My confusion is increased by the fact that if I print out next-props
from within will-receive-props, it appears on the console to be a plain
vector, but in the next line of code, where I use it in om/set-state!, it
is in fact a cursor.
Is this a prob
I'm having some problems unit testing Om components and how they update state.
For example:
(defn example-handler [{:keys [foo]} data]
(om/update! data :foo foo))
Because om/update! requires a cursor there's no obvious way to test this in
isolation.
What would be the standard approach to wri
Cursors cab be easily mocked. Probably a good blogpost for someone to write
:)
On Wednesday, September 3, 2014, Richard Layte
wrote:
> I'm having some problems unit testing Om components and how they update
> state. For example:
>
> (defn example-handler [{:keys [foo]} data]
> (om/update! data
Putting cursors into state is not a good idea.
On Wednesday, September 3, 2014, Daniel Kersten wrote:
>
> On 3 Sep 2014 06:51, "Alan Shaw" > wrote:
> >
> > PS My confusion is increased by the fact that if I print out next-props
> from within will-receive-props, it appears on the console to be a
David, can you give more details why? Is it because what it points to may
become invalid if the app-state changes?
I'd have to dig up code where I've actually done it, I can't think of any
offhand but I'm sure I have and haven't had any issues, but I can
understand why it might be a bad idea!
How
It just isn't a good idea. They are two separate state management
mechanisms. You are bound to get burned eventually and it won't be
pretty. It may also be disallowed completely in the future.
David
On Wed, Sep 3, 2014 at 8:59 AM, Daniel Kersten wrote:
> David, can you give more details why? Is
Setting local state from app state was not my goal. My goal was to reflect
the changed app state in the display - not an unreasonable desire. If you
read my question again you'll see that setting local state was only one of
three ways I tried to accomplish that.
Again: I was unable to access the c
If for some reason you need to snapshot the value of a cursor during
render use om.core/value to do that.
David
On Wed, Sep 3, 2014 at 10:25 AM, Alan Shaw wrote:
> Setting local state from app state was not my goal. My goal was to reflect
> the changed app state in the display - not an unreasona
Wow you simply have not taken the time to read my question.
2014/9/3 上午7:28 於 "David Nolen" 寫道：
> If for some reason you need to snapshot the value of a cursor during
> render use om.core/value to do that.
>
> David
>
> On Wed, Sep 3, 2014 at 10:25 AM, Alan Shaw wrote:
> > Setting local state fr
Or I simply don't understand the problem or the question :)
On Wed, Sep 3, 2014 at 10:30 AM, Alan Shaw wrote:
> Wow you simply have not taken the time to read my question.
>
> 2014/9/3 上午7:28 於 "David Nolen" 寫道：
>
>> If for some reason you need to snapshot the value of a cursor during
>> render
OK let me try this:
(render [_] (dom/h1 nil (:text app)))
App is a cursor but here we are happily getting the :text member of its
value by pretending app is the value.
(Something something (f app))
App is a cursor but here I am not magically given its value.
Discuss.
2014/9/3 上午7:41 於 "David N
I think it will be more fruitful to describe your problem with a
minimal bit of code completely outside the context of what you are
working on. As it stands I cannot even see the trouble you are having.
David
On Wed, Sep 3, 2014 at 10:48 AM, Alan Shaw wrote:
> OK let me try this:
>
> (render [_]
Thanks, I will do that. In the meantime it would help me if you could
describe the conditions under which saying "cursor" provides its value
rather than the cursor object?
2014/9/3 上午8:00 於 "David Nolen" 寫道：
> I think it will be more fruitful to describe your problem with a
> minimal bit of code
om.core/value during rendering, deref anywhere else
On Wed, Sep 3, 2014 at 11:08 AM, Alan Shaw wrote:
> Thanks, I will do that. In the meantime it would help me if you could
> describe the conditions under which saying "cursor" provides its value
> rather than the cursor object?
>
> 2014/9/3 上午8
So it is OK to take (.-value cursor) in render-state?
--
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 receivi
It is not. Use om.core/value
On Wed, Sep 3, 2014 at 2:29 PM, Alan Shaw wrote:
> So it is OK to take (.-value cursor) in render-state?
>
> --
> Note that posts from new members are moderated - please be patient with your
> first post.
> ---
> You received this message because you are subscribed to
I'm making my CI team at work nervous by relying on -SNAPSHOT releases in our
ClojureScript application, but bug fixes seem to sit in deployed snapshots for
some time. I'm currently relying on [cljsbuild 1.0.4-SNAPSHOT] and [weasel
0.4.0-SNAPSHOT].
Is there a reason why bug fixes aren't deploy
Ahh thanks!
2014/9/3 上午11:48 於 "David Nolen" 寫道：
> It is not. Use om.core/value
>
> On Wed, Sep 3, 2014 at 2:29 PM, Alan Shaw wrote:
> > So it is OK to take (.-value cursor) in render-state?
> >
> > --
> > Note that posts from new members are moderated - please be patient with
> your
> > fir
Alan, if you haven't read this page, it's very helpful:
https://github.com/swannodette/om/wiki/Cursors
Jamie
On Sep 3, 2014, at 3:21 PM, Alan Shaw wrote:
> Ahh thanks!
>
> 2014/9/3 上午11:48 於 "David Nolen" 寫道：
> It is not. Use om.core/value
>
> On Wed, Sep 3, 2014 at 2:29 PM, Alan Shaw w
I went digging and the code where I set local state to cursor data was
actually old code and I was missremembering it :-)
All of my new code does actually strictly separate the two mechanisms so
that app state refers to the domain data (the what) and local state refers
to the state of widgets (the
Minor correction: did-update should be (= prev-props data). It gets the
"old" cursor value as it's argument.
On 4 Sep 2014 00:50, "Daniel Kersten" wrote:
> I went digging and the code where I set local state to cursor data was
> actually old code and I was missremembering it :-)
> All of my new c
> make-animations should be able to work with (:circles cursor) without
knowing or caring if it gets given a cursor or not - cursors are quite
transparent.
I agree that it should be able to. However it is not doing so.
In the component where I am calling make-animations, the cursor is
(:circles cu
-A
--
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 clojurescript+
Never mind. I must use :tx-listen.
On Wed, Sep 3, 2014 at 6:31 PM, Alan Shaw wrote:
> -A
>
>
--
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 u
Are you able to show the exception that gets thrown? Also can you perhaps
share the make-animations code?
It "should" work as I pass cursors around all the time without issue... The
only time this causes problems for me is if I pass it to something that
gets run outside the render phase (eg js/setT
25 matches
Mail list logo
