I've been quite happily and successfully using kioo to construct my DOM
nodes and its been a pleasant experience and allowed me to avoid having to
(apply dom/x ...)
om/trasnact! working differently from swap! has bit me once or twice too. I
don't find it a big deal, but it would certainly help my memory :)
As for om/build - I sometimes use {} when the component doesn't actually
rely on state. I do agree that perchaps (om/build component cursor) should
build as it currently does whereas (om/build component [cursor]) would call
build-all, since (I assume) it can tell them apart because the former
om/cursor? would return true and the latter it wouldn't. On the other hand,
I like the explicitness of om/build-all - it makes it obvious to me at a
glance that its mapping over a list and constructing components instead of
constructing just a single component. If om/build were adapted to both use
cases, it would take more mental energy to figure this out. Also, I've
often used om/build-all on a cursor containing a list to build a component
for each element. This wouldn't be possible if it relied on whether or not
its a cursor or a list of cursors...
So with all of that said, in my humble opinion, I'm ok with leaving the dom
wrapper as is, I would be happy if transact! followed the same api as swap!
and I think build vs build-all should stay as it is.
On 11 May 2014 17:57, Christian Johansen <[email protected]> wrote:
> kl. 18:47:12 UTC+2 søndag 11. mai 2014 skrev David Nolen følgende:
> > On Sun, May 11, 2014 at 12:41 PM, Christian Johansen <
> [email protected]> wrote:
> >
> >
> >
> > kl. 18:25:33 UTC+2 søndag 11. mai 2014 skrev David Nolen følgende:
> >
> >
> > > Excellent point Norman! Sablono & Kioo are both great tools, I
> recommend them to anyone who's looking for something richer than the
> existing Om/React's DOM abstraction.
> >
> >
> >
> > Those do look very nice, but I don't think add-ons like these make any
> attempt at improving the usability of the core Om APIs superfluous.
> >
> >
> >
> > Christian
> >
> >
> > We just use the React.DOM stuff directly as it is just not something I
> want to spend time and energy on.
> >
> >
> > I admit the Om component stuff could be improved somewhat but a lot of
> this depends on React providing a better stable lower level API. I've been
> going back and forth with them about this - when they provide better hooks,
> we will also be able to provide something more uniform. But until this
> happens I don't see the current API changing much.
> >
> >
> >
> > David
>
> Makes sense, thanks for chatting.
>
> Christian
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/clojurescript.
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
