On Monday, March 17, 2014 11:51:32 AM UTC-7, Scott Nelson wrote:
> Thanks David! That works great. I made a root component that simply builds a
> new component based on the current route (updated the Gist).
One thing I might suggest is to avoid mutating app-state in your route actions.
Our team
Thanks David! That works great. I made a root component that simply builds a
new component based on the current route (updated the Gist).
--
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
Yes this isn't going to work. Om renders on requestAnimationFrame - this
means in your example there is a race condition between refresh and
changing the root component. This race condition is easily avoided by
making the current route a part of the application state.
David
On Sun, Mar 16, 2014
Here's a simple demonstration:
https://gist.github.com/scttnlsn/edcd40d617976880c7ba
Keep clicking the button and you should notice that at some point the counter
will increment, the route handler is called but the new view is not rendered.
--
Note that posts from new members are moderated - p
A minimal case that demonstrates the issue would be helpful, thanks.
On Saturday, March 15, 2014, Scott Nelson wrote:
> I think I'm experiencing something related to this. I have a few
> secretary (https://github.com/gf3/secretary) routes setup and each
> handler renders a root component into t
I think I'm experiencing something related to this. I have a few secretary
(https://github.com/gf3/secretary) routes setup and each handler renders a root
component into the document body. I'm encountering a strange timing issue
after doing the following:
- update the app state atom (this cau
You got me thinking : if we're storing drop-index, why not just use it during
the build phase as follows :
(apply dom/ul #js {:className "sortable" :ref "sortable"}
(flatten (map-indexed
(fn [idx item]
[(when (=
Hmm, really? How would you do it differently?
Seems like the perseus orderer uses the same technique (slicing out the card
you're about to drag, and inserting a placeholder at that index instead)
On Friday, February 7, 2014 10:25:41 AM UTC-8, David Nolen wrote:
> Without a minimal case it's h
Without a minimal case it's hard for me to understand what the problem is.
I will say the spacer technique in my sorting example was a simple hack and
not the way I would do a sortable - I suspect it may be the source of some
of these issues.
On Fri, Feb 7, 2014 at 1:14 PM, David Pidcock wrote:
I have been thinking about this a little bit.
Perhaps the interesting thing to me is not that the item-map might have changed
some value within it between render and click, it's actually that the line item
component is referring to a different item entirely, than the one it rendered.
So even
Well that didn't work :D
I actually got that the wrong way around.
Looks like the best way to pass the correct value is to use destructuring to
get access to the value at the time the function is invoked and pass that value
along to any handlers, not the atom/cursor (or use something like (int
Yes, I am still getting my head around this -- that the rendering of the item
can be out of sync with the atom it was handed is still a little wonky to me. :)
I'm wondering if it isn't better to simply avoid the destructuring and pull out
the data with (:key @atom) everywhere. I will experiment
Cases like this are to be expected and may need to be explicitly handled.
Dereferencing data will always give you something current which may not be
what the handler closure was given.
David
On Thu, Feb 6, 2014 at 6:47 PM, David Pidcock wrote:
>
> There appears to be some strange timing issue
There appears to be some strange timing issue in my application.
I am using a variation on the sortable example, but instead of using internal
state to represent the order of the items, I am using a sort-by function over
the app-state.
I suspect that externalizing this ordering is the source
14 matches
Mail list logo
