I would be very interested in learning about how to use replikativ: what
can and can't it store, when is and isn't it a good fit, demo/sample code
of common and not so common use cases etc
I've looked at replikativ and even went down the "learn lots about CRDTs"
rabbit hole and think I have an OK
I actually built a debug panel that was only included when running from
figwheel. This panel displayed my state and also logged all signals, so I
could always inspect what was triggered.
Over all it suited my needs and worked out well. It could probably have
been designed without needing this but
I was working on an app last year where I separated events that are
triggered in the components (I called them signals) and events handled by
handlers (I called these events as these are the normal re-frame events)
and then you could map signals to events. By default, a signal was the
event of the
I assume the reason that you can't simply register two handlers for the
same event is that order of execution then becomes non-deterministic. This
can be problematic (and hard to detect!) if you have two handlers for the
same event that access the same state. By simply not allowing more than one
I've actually been looking at Replikativ (and CRDT's in general) over the
past ~3 weeks, so I'm very happy to hear that Replikativ is moving
forwards. It looks incredibly interesting.
On Wed, 20 Jan 2016 at 16:30 Thomas wrote:
> Looks very interesting and I suspect
On Wed, 26 Aug 2015 at 11:36 Thomas Heller th.hel...@gmail.com wrote:
Well, while we are on the topic perhaps we should mention the downside of
using Web Workers. For me it has been Data Transfer.
Since you can only transfer JSON type data between workers that usually
meant you had to
The browser does not support threads so neither can core.async.
To expand on that, core.async uses cooperative multitasking, which means
you have to give control back every so often so it can schedule other go
blocks to be run. Calls like ! will do this while they block (which is why
timeout
React refuses the synthetic event objects AFAIK.
On Wed, 22 Jul 2015 21:39 David Pidcock eraz0rh...@gmail.com wrote:
On Wednesday, July 22, 2015 at 1:31:16 PM UTC-7, David Pidcock wrote:
Thank you.
So expected behaviour :D
Quick clarifying question : when you say Events use the
Mueller kurtronaldmuel...@gmail.com
wrote:
On Wednesday, April 9, 2014 at 6:33:31 AM UTC-4, Daniel Kersten wrote:
Hi,
I'm trying to figure out the best way of structuring complex
applications in Om and I've hit a bit of a brick wall that I'm hoping
someone can help me with.
I
If they are removed from the dom, then the components get unmounted (and if
you toggle it back then it is mounted again). If you hide them with css but
don't remove them then they do not get unmounted/remounted.
Which you do depends on what you want, I guess, (and how expensive any work
you do in
If you store it in app-state, you can use ref cursors to access it. This
way you can separate global from local by storing it under a separate key
or something similar.
If the parent of your toggle component knows about the toggle component,
then it can merge this additional state (which it may
Err I mean your compiler options (whether or not you use cljsbuild)
On Thu, 9 Jul 2015 00:58 Daniel Kersten dkers...@gmail.com wrote:
Yes, you can set pseudo-names in your cljsbuild options:
https://github.com/clojure/clojurescript/wiki/Compiler-Options#pseudo-names
On Thu, 9 Jul 2015 00:47
Yes, you can set pseudo-names in your cljsbuild options:
https://github.com/clojure/clojurescript/wiki/Compiler-Options#pseudo-names
On Thu, 9 Jul 2015 00:47 Matthew Huebert mhueb...@gmail.com wrote:
According to the Closure Compiler FAQ, we can rename symbols with
longer/meaningful names to
Does *(apply .setAlign n [1 2 3])* work?
On Thu, 2 Jul 2015 at 13:23 Sonny To son.c...@gmail.com wrote:
I have setAlign method on a javascript object called n:
(.setAlign n 1 2 3)
I want to use apply to make the same call
(apply (.setAlign n) [1 2 3])
However that does work. Any
Can you confirm that amt is a reagent ratom and not a clojure atom?
The on-change in the second example is not correct - the anonymous function
is thrown away and the dispatch runs on render. You probably wanted this:
#(do (reset! amt (- % .-target .-value))
(re-frame/dispatch
That is how re-frame's subscribe works. All components require the re-frame
namespace and can call subscribe using a keyword to choose which
subscription to use, but you don't have to know where it is defined as its
loaded into an atom which the subscribe function accesses.
On Sat, 27 Jun 2015 at
*I could assign to window.someCLJSfunctionOrDataStructure from CLJS but I
think it may get renamed during Closure's advanced compilation or does it?*
If you use *(aset js/window someCLJSfunctionOrDataStructure
your-data-or-fn)* to set and *(aget js/window *
*someCLJSfunctionOrDataStructure)* to
Hi everyone,
I am working on a collection of web development libraries to accomplish
various tasks that I've found myself wanting or needing in recent months.
Collectively, I've dubbed them Erinite.
The first of these libraries is erinite/template, a Clojure(script) hiccup
transformation library
a chance I will try and look at how
hard it would be to swap out enlive for erinite. I really like the pure
data style of the transforms. I have often wanted that with both enlive
and kioo. Nice work!
Creighton
On Mon, Jun 8, 2015 at 3:15 PM, Daniel Kersten dkers...@gmail.com wrote:
Hi
How about writing an extern for the ga function? Presumably the closure
compiler will prevent name clashes then?
On Sun, 7 Jun 2015 13:59 Val Waeselynck val.vval...@gmail.com wrote:
Alright, I managed to get it to work.
I'm not expert enough in Closure to understand why, but what made it work
I haven't tried it yet myself, but I believe reagent.ratom/run! will let
you do what you want:
https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.clj#L7
Something like this should work:
(defn my-controller-for-concern-x
(let [source (subscribe [:])]
Sounds great. Definitely looking forward to blog post when you get to it!
On Wed, 20 May 2015 17:59 Dustin Getz dustin.g...@gmail.com wrote:
Is anyone out there working on a pattern of framework for isomorphic
ClojureScript?
Yes, I am, it's basically a shell Clojure/Pedestal app that calls
I looked at DomKM's server-side Om some months back, but that's about it.
I'm not really interested in running a ClojureScript server (Clojure is
much better suited for that), but performing 1st page render is something
I'm interested in (perhaps through an approach similar to DomKM's - ie
of all widget displayed. Mmmh... Interesting.
Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit :
From my understanding of it:
Use higher level states and decouple them somewhat from the data.
For example, games do have lots of dynamically changing data. In a modern
shooter
From my understanding of it:
Use higher level states and decouple them somewhat from the data.
For example, games do have lots of dynamically changing data. In a modern
shooter you might have dozens of characters with positions, orientation,
velocity, health information, weapons, ammunition, etc
I agree, Colin. I read his conclusion that FSM's are great and not so hard
I once you're used to them but that until you're well enough versed they
seem too much effort (YAGNI) and when the code is complex enough that it's
no longer the case, it's to expensive to change.
I'll definitely check out
I remember I had similar issues before and I believe the problem ended up
being in the wrong namespace, or something like that.
I can't test this myself right now, so can't check exactly what it is I had
to do, but try switching to the namespace where the var you want to modify
is before
Great, glad I could help :)
On Sat, 16 May 2015 18:35 Matthew Phillips matt...@matthewphillips.info
wrote:
Changing namespaces did indeed cure my ills! I'll keep that in mind
when trying to modify state in the REPL in the future. Thank you.
On Sat, May 16, 2015, at 12:45 PM, Daniel
I would assume you're right that very few are transient. At least with
Mikes approach, you can log the error, notify the user and continue working
from a clean state (but I assume if the user does the same thing again the
error would happen again - that is, they can continue doing other things).
+10, Daniel Kersten wrote:
Personally I find that moving state out of components as re-frame's
subscriptions and handlers encourage is a desirable trait and would be
cautious about reintroducing local state.
Keeping my data in one place (and handling updates and queries through
Personally I find that moving state out of components as re-frame's
subscriptions and handlers encourage is a desirable trait and would be
cautious about reintroducing local state.
Keeping my data in one place (and handling updates and queries through a
centralised place) has made it a lot easier
As far as I know, in compile simple identifiers are not renamed, so externs
are not needed.
On Wed, 13 May 2015 17:28 Jamie Orchard-Hays jamie...@gmail.com wrote:
Thanks, David. That could be the problem. When using :compile :simple, are
externs ignored?
Cheers,
Jamie
On May 13, 2015, at
Ouch! But that actually makes a lot of sense.
On Mon, 13 Apr 2015 14:58 Alex Miller a...@puredanger.com wrote:
There is a ticket to consider a portable solution to this issue:
http://dev.clojure.org/jira/browse/CLJ-1293
On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote:
Oops, obviously I meant #(dispatch ...)
On Fri, 3 Apr 2015 at 12:53 Daniel Kersten dkers...@gmail.com wrote:
The queues are FIFO since it's using core.async under the hood. Obviously
if you have things like server putting events on the queue, you can't
guarantee order, but relative order (eg
The queues are FIFO since it's using core.async under the hood. Obviously
if you have things like server putting events on the queue, you can't
guarantee order, but relative order (eg doing two dispatches one after
another) will be in order.
Yeah, I'd probably do with something like:
(let
Right, I see what you mean. I think I need to think about it some more :)
On Fri, 3 Apr 2015 at 12:58 Rafał Cieślak ravici...@gmail.com wrote:
That is, have the event control which player it gets applied to. This
way the handler does not need any knowledge of this at all and can use path
Have you tried using dispatch-sync?
https://github.com/Day8/re-frame/wiki/Bootstrap-An-Application#a-cheat and
https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljs#L54
On Fri, 3 Apr 2015 at 22:50 Karsten Schmidt i...@toxi.co.uk wrote:
I've been really enjoying my last month
is given the _same_ snapshot
of the database in which case event dispatch sequence is irrelevant,
or the db is the result of reducing each handler onto the snapshot.
I really should check the code (but head elsewhere ATM).
On 3 April 2015 at 13:07, Daniel Kersten dkers...@gmail.com wrote:
Right, I
[foo bar] makes a new react component, (foo bar) is just a function call.
So in your second example, [make-rows ...] is a component itself and
therefore gets rerendered when its subscriptions change - just like every
other component that gets rerendered when its data changes. The former is a
I'm currently tinkering with an approach where my code does not dispatch
re-frame events at all, but rather uses my own emit function to emit
signals[1]. I then, separately, have a signal-event map, so the (single
global) signal handler then maps signals to events and dispatches these
events to
Marc, can you tell us a little more about the approach your taking?
On Fri, 27 Mar 2015 at 17:43 Marc Fawzi marc.fa...@gmail.com wrote:
Yeah but then what are you really reusing? I have components that have
sophisticated behavior... sharing just the markup and styles is of limited
value since
. I know I am going to kick myself...
On Friday, 27 March 2015 00:54:46 UTC, Wei Hsu wrote:
If you want each client to be unique, what if your user-id-fn could
just generated a UUID?
On Thursday, March 26, 2015 at 9:19:11 AM UTC-7, Daniel Kersten wrote:
I actually would like to do
@Dj3bbZ
On Fri, Mar 27, 2015 at 6:45 PM, Daniel Kersten dkers...@gmail.com
wrote:
Marc, can you tell us a little more about the approach your taking?
On Fri, 27 Mar 2015 at 17:43 Marc Fawzi marc.fa...@gmail.com wrote:
Yeah but then what are you really reusing? I have components that have
Excellent, thanks!
On Fri, 27 Mar 2015 at 20:00 Marc Fawzi marc.fa...@gmail.com wrote:
Yes, for sure.
On Fri, Mar 27, 2015 at 12:56 PM, Daniel Kersten dkers...@gmail.com
wrote:
I'm not in SF either (or even the same continent) so would very much
appreciate slides/videos/blog posts
Thanks for sharing this.
On Fri, 27 Mar 2015 at 20:39 Marc Fawzi marc.fa...@gmail.com wrote:
This is the video from our last Reagent SF Meetup. It shows the Minority
Report like interactive Data Visualization by Weidong Yang as well as an
intro to Reagent, the ClojureScript React wrapper,
I actually would like to do the same thing. For authentication, I would use
a JSON Web Token and would happily pass that with my requests manually. I
don't care if client id's change because my server is stateless-REST-like.
On Thu, 26 Mar 2015 at 15:22 Colin Yates colin.ya...@gmail.com wrote:
Try setting :pseudo-names to true:
https://github.com/clojure/clojurescript/wiki/Compiler-Options#pseudo-names
This way you can at least see which identifiers got renamed during
optimisation.
On Thu, 26 Mar 2015 at 17:22 Jonathon McKitrick jmckitr...@gmail.com
wrote:
I'm about to make a
I did the same. Started a new reagent figwheel project and added re-frame
as a dependency manually.
On Wed, 25 Mar 2015 15:01 Colin Yates colin.ya...@gmail.com wrote:
Thanks Jamie.
On 25 March 2015 at 14:59, Jamie Orchard-Hays jamie...@gmail.com wrote:
I've been playing with it the past
I've been using Om (and therefore cursors) heavily for almost a year and am
finding myself moving further and further away from cursor. The issue for
me is absolutely the write-back - allowing your views to write to them
encourages your code to do so and encourages a style where your ui/dom
event
unidirectional data flow and have ui/dom events only
dispatch messages back. So view model data - ui - messages
Ah! Enlightenment.
Thank you.
On Wed, Mar 4, 2015 at 3:51 PM, Daniel Kersten dkers...@gmail.com
wrote:
I've been using Om (and therefore cursors) heavily for almost a year and
am
I've used it. I posted some information on Stackoverflow:
https://stackoverflow.com/questions/23368485/creating-animations-with-clojurescript-om/27127541#27127541
On 19 February 2015 at 10:38, Michael Ravits michaelr...@gmail.com wrote:
Hi,
Has anyone used the ReactJS animation addon with Om
I personally like data. om-tools also calls it data.
On 2 February 2015 at 12:55, Khalid Jebbari khalid.jebb...@gmail.com
wrote:
Indeed, data is better than app.
Khalid aka DjebbZ
@Dj3bbZ
On Mon, Feb 2, 2015 at 10:49 AM, Sebastian Bensusan sbe...@gmail.com
wrote:
Thanks Khalid,
The
A figwheel-based tutorial would be fantastic.
I don't have an awful lot of time to convert it right now, but if nobody
does before I do get time, I'll happily take a stab at it. Will likely be a
month or two though.
On 27 January 2015 at 16:24, David Nolen dnolen.li...@gmail.com wrote:
I think
Thanks David for your continued hard work - another fantastic release. This
looks really good and solves real problems.
On Sat, 24 Jan 2015 16:09 David Nolen dnolen.li...@gmail.com wrote:
On Sat, Jan 24, 2015 at 11:01 AM, Khalid Jebbari khalid.jebb...@gmail.com
wrote:
A question (maybe
For future reference, I find searching clojars useful to fix issues like
this. Eg if you look for 0.8.1 on this page:
https://clojars.org/search?q=om
On Sat, 24 Jan 2015 08:56 Oliver George oli...@condense.com.au wrote:
Happens to the best of us.
On Sat, Jan 24, 2015 at 7:54 PM, Zubair
Wow you're awesome! Thanks for this. That's basically what I was planning
on doing, so you've saved me a ton of time! Excellent work.
On Fri, 16 Jan 2015 21:52 Taylor Sando taylor.sa...@gmail.com wrote:
I was playing around with it yesterday and today:
There's not a CDN, or pre-built
Hi Sam,
No, it will be Saturday before I get time to start. But, yeah, I'd be happy
to collaborate!
On Wed, 14 Jan 2015 02:51 whodidthis ton...@gmail.com wrote:
On Wednesday, January 14, 2015 at 3:04:42 AM UTC+2, sam wrote:
On Sunday, January 11, 2015 at 9:36:19 AM UTC-5, Daniel Kersten wrote
I assume it depends on Google closure compiler. Unless this is something
that optimization none would avail of, but I don't see why it would.
On Tue, 13 Jan 2015 15:37 Robin Ricard ricard.ro...@gmail.com wrote:
Maybe Traceur Compiler[1] could be used to keep backward compatibility
with older
I use ClojureScript because I like Clojure and want to use it, but my work
requires me to write code for the browser. ClojureScript allows me to wrote
Clojure in the browser. I also never really got into and therefore never
enjoyed writing Javascript, so this way I can still program for the
It's pretty new so I guess it really is still a work in progress, but I
find the text confusing as it makes it sounds like the documentation site
is what's still a work in progress.
In any case, I'm also very interested in porting this to Om. I'm thinking
an auto generated wrapper like what
Re #2, for me this is interesting for performance than anything else. Ie
loading only what is needed, when needed.
David, do you have a link or anything for closure modules by any chance?
Despite being a search company, I've found it difficult to turn up much in
the way of documentation. I did
Looks very interesting. I'll be watching this for sure!
On Sat, 27 Dec 2014 22:06 whodidthis ton...@gmail.com wrote:
On Friday, December 26, 2014 7:03:34 PM UTC+2, Nikita Prokopov wrote:
Hi everybody!
I want to announce a preview of new CLJS UI library based on React. It
aims to replace
I always communicate values to children to keep them decoupled from their
parents. I don't think there's any technical reasons to avoided your
approach, but I don't like components relying directly on the structure of
other components.
I also try to represent the bulk of my state in the cursor
Minor typo correction:
I know if my components use *-nr! functions because all of my state
access is local to the function
That was meant to say local to the component.
On Mon, 15 Dec 2014 08:54 Daniel Kersten dkers...@gmail.com wrote:
I always communicate values to children to keep them
Apparently David is relaxing the restriction of not being able to access
cursor outside of the render phase without dereferncing, although it's my
understanding that deref is still necessary if you require an up to date
view of the cursor, so it's probably still variable to make the distinction
This is great! Thanks for sharing. Looks really flexible. I'm looking
forward to replacing my own sightly buggy easing functions with this. :)
On Sun, 14 Dec 2014 17:47 null pande...@gmail.com wrote:
Yeah I can imagine it isn't easy to test that stuff well. (So it wasn't
directly cljx/cljs
The first argument to om/root is a function, the second argument is the
application state. Ones a function, the other is state.
That function, when called (typically by om/build, but in the case of
om/root, its called internally) returns an instance of the Om component.
You never use this
To see why you cannot pass changing information in opts:
The Om component function returns a reified instance of the protocols:
(defn my-component [app owner opts]
(reify
om/IRender
(render [_] (dom/div nil (:foo opts
The first time om/build is called with this and opts is passed
I don't like this approach: rendering every 'page' but making them all
hidden except for the current one. It seems rather wasteful. (Also means
you cannot make use if ReactCSSTransitionGroup for animating)
The other approach works well though.
On Tue, 9 Dec 2014 16:26 Colin Yates
Since the data you want to change is the app-state, the simplest (and most
Om-like) thing to do is to have choice transact! or update! the data
directly. This may require you to make each choice a map or vector (rather
than eg a boolean) so that it remains a cursor:
(def app-state (atom
involves
the setup, putting, taking, and properly closing of channels, which, while
useful perhaps for larger mechanisms, seems like overkill for quite simple
needs.
On Wednesday, May 28, 2014 2:55:53 AM UTC+2, Daniel Kersten wrote:
I use core.async for this - pass a channel to the child, have
Ah I just looked at the code: the past issues with multimethods were when
you use one directly as an om component, but you are using it to call
build, so your problem is unrelated after all.
It does sound like a bad idea to build components and then pass them around
rather than passing the
, parent etc which is then accessed during calls to
build.
On 4 December 2014 at 14:05, Daniel Kersten dkers...@gmail.com wrote:
Ah I just looked at the code: the past issues with multimethods were when
you use one directly as an om component, but you are using it to call
build, so your problem
:11:51 UTC, Daniel Kersten wrote:
Ok, just checked Om source - build does in fact rely on the component it
is built in, so passing a built component into another component to be
rendered there is definitely not a safe thing to do!
Render uses (binding [...] ...) to capture details
I think extra validation for Dev would be great. The more mistakes you
can't make without being caught the better! Would make Om more beginner
friendly too. So +1 from me too.
On Thu, 4 Dec 2014 17:06 David Nolen dnolen.li...@gmail.com wrote:
https://github.com/swannodette/om/issues/287
To mirror what David is saying: :none compiles my code (with cljsbuild
auto) in under 400ms in VirtualBox (yep, I've an odd dev environment),
:whitespace can take a second or even two.
However, I have found :whitespace and :simple useful for debugging before
when a bug manifested in :advanced but
.
David
On Wed, Nov 26, 2014 at 2:08 PM, Daniel Kersten dkers...@gmail.com
wrote:
To mirror what David is saying: :none compiles my code (with cljsbuild
auto)
in under 400ms in VirtualBox (yep, I've an odd dev environment),
:whitespace
can take a second or even two.
However, I have found
I haven't reviewed the ominate code in a while so would need to look at it
again. Check the branch, however, as it was slightly more up to date.
As for unmounting and remounting, that used to be a bug yes but AFAIK this
is no longer the case (since the multimethods fix)
On Mon, 17 Nov 2014 13:00
You have the right idea. I believe the mistake in your code is that
om/build is being called outside of render (or a function called by
render). If you change your code to something like the following, it should
work:
(defn default-view [app owner opts]
(om/component (dom/h1 nil Default View)))
I didn't ask for feature expressions in the survey, but I've been wishing
for a better way for writing cross-target code, especially libraries.
I've never quite managed to bring myself to develop with cljx - I love it
as a consumer of libraries, but I haven't quite managed to make it wo
wellrk in
Just to add: one really shouldn't pass anything to :opts that changes
during the lifecycle of the component. The component will *not *see these
changes. I've also observed some problems if opts changes (components
getting unmounted and remounted), so best to avoid it altogether if
possible.
On 3
You could probably find or write a script or leiningen plugin to send
errors to growl or other notification system.
On Mon, 10 Nov 2014 00:20 Glen Mailer glenja...@gmail.com wrote:
Cheers for the advice everyone.
For some reason I had assumed warnings would appear in the js console, but
of
I've found this troublesome too when starting out. The compiler does catch
the obvious cases but there's still many that slip through. I found that
I'm more careful now and overall don't find it too troublesome anymore. I
guess you just get used to it. It would be nice if the compiler could warn
Re: Om book, I think it's still a bit too early since the idioms and best
practices are still largely being figured out.
A crowd sourced book that can be quickly updated as Om gets more and more
battle tested could work, but for now I think contributing to the official
docs and tutorials to bring
This is great! Thanks very much. I will play with this over the coming days.
On 30 October 2014 01:05, Kyle Dawkins kdawk...@fastmail.fm wrote:
Hey all
A few weeks ago I spent some time porting
https://github.com/stuartsierra/component to ClojureScript. The results
are here:
github:
Yes, you should terminate the go block in will-unmont, otherwise if your
component is mounted multiple times, you will end up with multiple go
blocks consuming from the channel. If you are transacting on a cursor, then
this will just eat up resources, but if you are accessing owner (eg to
get/set
collection thing happening.
Do you happen to have a quick example of how to use the om-tools mixin
to automatically unsubscribe?
Thanks!
On 30 October 2014 20:24, Daniel Kersten dkers...@gmail.com wrote:
Yes, you should terminate the go block in will-unmont, otherwise if your
component
I personally like keeping the incidental local state local to components
and keep the app state purely for domain data. Therefore I would use the
local state like you said and use the cursor only to point at the tag list
being modified.
As for how to manage the local state with sub components,
, Daniel Kersten dkers...@gmail.com wrote:
I personally like keeping the incidental local state local to components
and keep the app state purely for domain data. Therefore I would use the
local state like you said and use the cursor only to point at the tag list
being modified.
As for how
,
Any updates on this issue in terms of - how do I access different
parts of the app state from different locations?
Thanks!
On Wednesday, April 9, 2014 3:33:31 AM UTC-7, Daniel Kersten wrote:
Hi,
I'm trying to figure out the best way of structuring
I call om/root from a doseq and it's worked fine for me.
Do you see any errors in the js console? Does num-list get called?
On 3 Oct 2014 03:27, gvim gvi...@gmail.com wrote:
To create a static componenet I can attach this to a select
id=day1/select tag:
(defn num-list [start end text]
:key is a keyword which is used to look up app state (as pointed to by the
cursor passed to build) and the value found there is then used as the react
key.
:react-key is a value (eg a string) which is used as the react key directly.
For example:
(om/build my-component {:foo hello} {:key :foo})
and cleaner code by providing a simpler
and more focused API.
On Saturday, September 13, 2014 1:22:31 PM UTC-4, Daniel Kersten wrote:
It sounds like Reafent naturally encourages this model while with Om
there's a tendency to put everything into one atom - until you learn
through experience
too limited for what I
needed. The trade-off is much more to think about (complexity) when writing
Om components.
Jamie
On Sep 9, 2014, at 3:51 AM, Daniel Kersten dker...@gmail.com
wrote:
My apologies
the subject, but keeping the thread. Apologies to those whose
email readers may get confused... :)
On Sep 9, 2014, at 9:37 AM, Paul Butcher p...@paulbutcher.com wrote:
On 9 September 2014 at 08:52:01, Daniel Kersten (dkers...@gmail.com)
wrote:
I'm just trying to get a better understanding
You can put seqs in IFF you don't rely on them being cursors later.
I find it easier and safer to make sure they're always cursors. A place
this has caught me out is transferring seqs over Websocket and putting them
in app state. Now I always call vec (or use mapv or other alternatives as
My apologies for an off topic post in this thread - we can take it off list
or to a separate thread if it needs more than a simple reply - especially
since the library looks really good!
Sean could you write a little about why you switched away from Om?
I'm just trying to get a better
I personally avoid doing anything impure in IInitState. To me it seems that
it should be a pure function returning a map of the local state. IWillMount
is a better place to do things.
Could you perform the updates in the parent?
On 5 September 2014 10:23, Zubair Quraishi zuba...@gmail.com
On 3 Sep 2014 06:51, Alan Shaw noden...@gmail.com 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.
Daniel. I can confirm that
cljs.core.async.impl.channels.ManyToManyChannel.closed gets set to true after
my component is unmounted and (! subscriber-ch)subsequently returns nil,
so it looks to be working as expected!
Cheers,
Dhruv Bhatia
On Aug 31, 2014, at 8:48 PM, Daniel Kersten dkers
1 - 100 of 184 matches
Mail list logo