ClojureScript DOM-manipulation library?
Shantanu Kumar
There are several JavaScript libraries that can probably be wrapped,
but a ClojureScript library should be great. I noticed a short
comparative list of jQuery basic operations vs JavaScript equivalent
that looks interesting: http://sharedfil.es/js-48hIfQE4XK.html
Shantanu
Mark Rathwell
stuff. Were you thinking more than that?
[1] https://github.com/ibdknox/pinot
[2] https://github.com/ibdknox/pinot/blob/master/src/pinot/dom.cljs
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Shantanu Kumar
On Jan 6, 1:23 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote:
> Pinot [1] provides some dom manipulation [2], mostly wrapping goog.dom
> stuff. Were you thinking more than that?
Shantanu
ckirkendall
finished it up but haven't announced it yet. It started out as a port
of enlive to ClojureScript but has evolved into something much more
powerful. I covers everything from event handling, effects and
standard transformations. Below are links to the github and demo
site.
Demo Site:
http://ckirkendall.github.com/enfocus-site/
Github:
https://github.com/ckirkendall/enfocus
Creightion Kirkendall
kovas boguta
I've created a jquery wrapper conveniently called cljs-jquery ,
however there is no documentation, tests, or general housekeeping yet
so haven't announced it. If you are brave,
https://github.com/kovasb/cljs-jquery
Previous libraries have followed the lead of the initial Clojurescript
examples, and tried to wrap gclosure to make it more
clojure-idiomatic.
I think this whole approach is a mistake.
This is not a generic data processing problem, so we shouldn't be
converting the dom into verbose generic clojure structures with
namespace prefixes everywhere.
DOM manipulation is ideally suited to a DSL. JQuery already defines
the primitives, and provides the implementation. Lets just wrap it.
The idea of my library is trivial. Just have a macro that expands into
a jquery call chain:
$(selector).f(a,b).g(c,d)
is represented by
($ selector (f a b) (g c d))
(note that f and g don't need buzz-killing namespace prefixes)
For bonus points, selector can be a hiccup structure (or a hiccup
structure with embedded dom objects) which ends up saving a huge
amount of code when creating new elements.
In general this is far more concise and easier to code than any other
approach I've seen thus far.
On Fri, Jan 6, 2012 at 3:16 AM, Shantanu Kumar <kumar.s...@gmail.com> wrote:
Chris Granger
Kovas that wrapping the goog libs aren't really the way to go. For
one, I was basically replicating aspects of jQuery (like event
delegation).
Recently I started on doing some thing that makes jQuery play in the
Clojure world really nicely. I'll get this onto github soon.
Cheers,
Chris.
On Jan 6, 5:18 pm, kovas boguta <kovas.bog...@gmail.com> wrote:
> Yes.
>
> I've created a jquery wrapper conveniently called cljs-jquery ,
> however there is no documentation, tests, or general housekeeping yet
kovas boguta
enough of a JS pro to be the one doing this.
I think what matters is the design. Jquery is an accessible
implementation target, but if someone wants to retarget the design to
gclosure, thats fine too (just more work than is need to get started)
On the design front, there is a fundamental difference between a DSL
and the "standalone generic function" style. So I want to point this
out and advocate for other design decisions I made, to stir the pot
here.
Generic function style treats dom manipulations as stand-alone functions, like
dom/append, events/on, etc
The theoretical benefit is 1) you can use generic clojure functions to
manipulate these datastructures, and 2) you can insert your own
functions into the call tree at any point, like
(dom/append (events/on (your-function (dom/query X)) Y) Z)
However the set of useful dom manipulations is a well-understood, and
is closed set (dom in, dom out). So there is not much benefit in this.
And in fact it tends of obfuscate the code, due to the namespace
prefixing, and also because the dom manipulation sequence is not
clearly set apart from other code. You have to remember how
clojure-like a given return value is.
Better to have a clear sequence like
($ X (click Y) (append Z))
This also has the additional advantage that $ can do a variety of
important tasks, including taking care that "this" is properly
handled. In my library ($ :this) is its javascript equivalent at the
current evaluation context, so handling events is easy.
There are other extensions worth considering. Things like
($ <selector> (css <attribute> <atom>))
could wire an atom to a css (or other) dom attribute, by placing a
watcher on the atom and automatically updating the dom on change.
In general, a high-level cljs dom manipulation framework can consume
atoms (in addition to values) in a variety of places, thus creating
auto-updating views.
We can also leverage clojure maps to aggregate attribute-value pairs, like
($ <selector> (css {<a1> <v1> <a2> <v2}))
Finally, I'm just gonna reiterate that I am a major fan of allowing
<selector> to be an arbitrary hiccup structure, with the extension
that dom/jquery objects are allowed as entries in the hiccup vector.
This makes composing things easy.
ckirkendall
I am interested in your challenges. For Enfocus I had to implement
several features that existed in jquery around events (mouseenter,
mouseleave, window resize) but I wanted to keep the stack pure without
any external dependencies. Enfocus might have been easier to
implement if I had chosen JQuery but I was afraid that requiring an
external dependency might be problem. I was able to port all of
enlive transformation and quite a bit more. It provides similar model
as JQuery where I have selector -> action. Overall, I did not find it
overly difficult to use the goog libraries for this.
CK
Shantanu Kumar
projects.
Shantanu
Takahiro Hozumi
Ryan Waters
> I think what matters is the design. Jquery is an accessible
> implementation target, but if someone wants to retarget the design to
> gclosure, thats fine too (just more work than is need to get started)
>
Chris and Kovas -
By going with jquery how well does your clojurescript compile-time
check and minify? Have you written anything that sufficiently tests
compatibility with the gclosure compiler?
- Ryan
Dave Sann
Bobby Calderwood
github.com/levand/domina]. I'm using it in a project now with great
success.
