What's so special about JSX that isn't possible with kioo or sablono?
On Sun, Jun 22, 2014 at 4:20 AM, Paul Cowan dag...@scotalt.net wrote:
I think until it is markup the disconnect is far too removed to be
practical. I think we need jsx or nothing
On Sunday, June 22, 2014, Creighton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello again,
I am pleased to announce release 0.2.0 for hasch, a library to
consistently hash edn in Clojure and ClojureScript.
Changes:
* Tagged-Literal support.
* Similar runtime dispatch on edn protocols in ClojureScript.
Christian
-BEGIN
Hi Andrew,
We ended up doing exactly the sort of thing you describe. We have a go
block inside IWillMount, listening for messages from the server (in our
case via browserchannel, but exact same idea). Inside this go block we
apply updates from our server by calling transact! on the app data.
Let's also not forget that JS is single-threaded. I'm guessing all the
components will be recursively mounted before the contents of the go block
can do anything at all.
On Sun, Jun 22, 2014 at 9:20 AM, Dave Della Costa ddellaco...@gmail.com
wrote:
Hi Andrew,
We ended up doing exactly the
That is the case that I've seen most often Gary.
On Sunday, June 22, 2014 9:24:32 AM UTC-4, Gary Trakhman wrote:
Let's also not forget that JS is single-threaded. I'm guessing all the
components will be recursively mounted before the contents of the go block
can do anything at all.
I would hope most anyone working on a web app would be familiar with
HTML markup (https://github.com/ckirkendall/kioo).
(2014/06/22 20:02), Paul Cowan wrote:
it is markup that everyone is familiar with?
On Sunday, June 22, 2014, Moritz Ulrich mor...@tarn-vedra.de
mailto:mor...@tarn-vedra.de
Sure, the main reason for us is to keep things modular. It makes it
simpler to restructure things, since it's just another component.
We wrap our root component in this invisible component, so it just
calls build on the root component itself (that is, the invisible data
listener component
I also use an invisible management component to handle updates from
outside of Om. Works great.
If you wrap your root with this component, everything should work just
fine, but if you create go blocks inside components that can be unmounted,
you have to remember to kill the go block from
PS:
My invisible component is a container for the actual root - so I don't
return an empty div, I return (om/build real-root-component app-state
options-passed-to-root)
On 22 June 2014 14:58, Daniel Kersten dkers...@gmail.com wrote:
I also use an invisible management component to handle
Thanks Daniel and everyone; this has been quite helpful.
On Sun, Jun 22, 2014 at 10:00 PM, Daniel Kersten dkers...@gmail.com wrote:
PS:
My invisible component is a container for the actual root - so I don't
return an empty div, I return (om/build real-root-component app-state
I have a go block in IWillMount here
https://github.com/dagda1/web-game-of-life/blob/master/src/cljs/app.cljs#L57
that is called periodically on a timeout function.
Do I run the risk of having multiple go blocks running? Should I be
killing the channel?
Cheers
Paul Cowan
Cutting-Edge
I think I didn't understand entirely what constitutes a mount and
unmount in Om; is an unmount similar to no longer calling build on a
component that was previously getting built and rendered? i.e. a
parent component decides to not call build any more on a child,
thereby removing it from the
On Friday, June 20, 2014 10:29:38 AM UTC-4, Jonathon McKitrick wrote:
I discovered that along with Om, there are Reagent and Quiescence.
Has anyone worked with the latter alternatives, and how might I decide what
the tradeoffs are for using each of them?
So tell me if this is accurate
Paul, no it looks like your good.
Basically, you only run the risk if the component in which the go block is
defined can be unmounted. A lot of components will never be unmounted
during the normal execution of the app. Also, I ran code that creates go
blocks in IWillMount for about a month before
Andrew, yes.
From my understanding, it works like this:
Om renders a tree of nodes. React diffs this tree with the previous version
that it rendered to the DOM. Any nodes that existed in the previous
version, but not in the current get unmounted.
On 22 June 2014 16:40, William Sommers
On 22 June 2014 at 16:32:29, Jonathon McKitrick (jmckitr...@gmail.com) wrote:
So tell me if this is accurate
1. Reagent has the simplest approach, with just the 'render' function for
React.js components, and a ratom (possibly one per component) for state.
Yes, but if you need additional
So far I'm using the following approach:
1.) use dom/render-to-str
2.) use hiccup to parse the result string and select the elements of interest.
Example:
(def input (seamless/create-input {:key :text}))
(deftest render-input
(is (= (:content (first (s/select (s/class span-value)
You may use the
defprotocol IDidUpdate
(did-update [this prev-props prev-state]))
function. This one is called when React has rendered the component into the
DOM. This would allow you to get the mouse position and update the state.
--
Note that posts from new members are moderated - please
I guess this is obviously why putting a go block in the topmost level om/root
is wise, since there would definitely not be internal logic which could unmount
it, as it has no Om parent.
Sent from my iPad
On Jun 22, 2014, at 11:58 PM, Daniel Kersten dkers...@gmail.com wrote:
Paul, no it
Interop with Google Closure libraries creates some issues as they
don't really follow Clojure namespace conventions at all. I don't
really see how to disallow things like that without causing more
trouble than it's worth. Open to any good ideas others may have.
David
On Sun, Jun 22, 2014 at 2:59
I guess js/goog.net.EventType and js/goog.net.XhrIo would have worked in
those cases?
My issue in Cursive is that resolving any symbol to its JS equivalent
(which would fix a lot of these cases I've asked about) caused a bunch of
spurious resolutions. For example, in one of my tests I had a
On Sun, Jun 22, 2014 at 6:44 PM, Colin Fleming
colin.mailingl...@gmail.com wrote:
I guess js/goog.net.EventType and js/goog.net.XhrIo would have worked in
those cases?
js/foo.bar.baz will always works.
David
--
Note that posts from new members are moderated - please be patient with your
On Monday, June 23, 2014 1:32:27 AM UTC+10, Jonathon McKitrick wrote:
On Friday, June 20, 2014 10:29:38 AM UTC-4, Jonathon McKitrick wrote:
I discovered that along with Om, there are Reagent and Quiescence.
Has anyone worked with the latter alternatives, and how might I decide what
the
itself in the right absolute position if the window resizes). Its
not that you can't do this in OM, of course, but, as I understand it,
you'd have to merge the window dimensions into the main atom, and
meaning the reusable popup component would require that every
app-state had these window
24 matches
Mail list logo
