Thanks Mike. Yeah, it is that ‘untidiness’ that happens when each subscription
is per row for example that made me question it…
On 9 Jun 2015, at 11:52, Mike Thompson m.l.thompson...@gmail.com wrote:
On Tuesday, June 9, 2015 at 8:44:02 PM UTC+10, Colin Yates wrote:
I understand that you can
Hi Ryan,
You can use core.async to create a process that has exclusive access to the
atom that holds all state. This greatly simplifies the structure of the client
application.
I wrote a tutorial on quiescent that uses this structure:
https://github.com/wvdlaan/todomvc
The tutorial is a bit
On Tuesday, June 9, 2015 at 8:44:02 PM UTC+10, Colin Yates wrote:
I understand that you can provide parameters when subscribing to something,
but I am unsure when it is idiomatic to do so. The example in the
documentation is for a static value (the number of results), but what about
if
I understand that you can provide parameters when subscribing to something, but
I am unsure when it is idiomatic to do so. The example in the documentation is
for a static value (the number of results), but what about if those parameters
change frequently.
For example, let's say I have a
Hi Damien,
FWIW, Reagent has been shown to work with React Native by chendesheng:
https://twitter.com/mfikes/status/607184835485048832
Yeah, I'll be at Cap-Clug tomorrow; look forward to chatting!
- Mike
--
Note that posts from new members are moderated - please be patient with your
first
http://dev.clojure.org/jira/browse/CLJS-1302
Will try to take a look at it soon.
Thanks for the report.
David
On Sun, Jun 7, 2015 at 9:28 PM, Alice Bellard dofflt...@gmail.com wrote:
On Monday, June 8, 2015 at 6:19:26 AM UTC+9, David Nolen wrote:
Google Closure needs to know about
It's a good example! Thank you.
With my current component it seems like a clean way to handle the issues of
passing functions to swap! that may or may not change the state of the atom
and wanting to perform side effects while I have data handy within the
swap! is to just avoid using atoms in
On Friday, June 5, 2015 at 8:24:54 PM UTC-4, Mike Fikes wrote:
Hey Daniel,
My guess is that nobody is working on this yet, at least for use with Om.
I'm also curious as to whether om.next will ultimately be required (and
whether this matters).
(So far, I've just made do with some very
