Cloact: Minimalistic React for ClojureScript
holmsand.github.ioWhile I haven't had any time to play with ClojureScript, Om, React, etc. I've been keeping a pretty watchful eye, because the stack looks very appealing.
One bit that doesn't look appealing to me in Om, or Cloact is the tree-building. Is there anything in ClojureScript and React right now that will let me build templates in HTML and attach functionality via attributes Angular-style?
As I suggest below I don't see why you could not compile to Om or Cloact from HTML for a friendlier presentation for designers. Still I don't think Cloact nor Om DOM syntax is particularly unapproachable for designers - I think we need some good documentation and some compelling, friendly walk-through demos (Light Table anyone? :)
Please yes (on the Light Table demo). I know my way around ClojureScript, and I cannot get the Om TODOMVC demo to run in Light Table. If I get it figured out, I guess I'll be the one writing the tutorial, but so far no dice.
> Still I don't think Cloact nor Om DOM syntax is particularly unapproachable for designers
It's not just designers who appreciate using declarative markup over programmatic syntax! Of all the people who might understand this, I'd have thought you would be the first in line (as a fan of your work on core.logic and inspiring me to learn prolog)!
I find the React approach very declarative. Certainly competitive with most of the templating systems I've used, few of which I can speak very highly of :)
I've used both dojo dijit and angularjs templates. I admit, I haven't done more than read your blog on Om, but I very much prefer the html declarative templates of both dojo and angularjs ... show me how Om/React beats direct html templates, I'm not seeing it.
I'm not trying to be too non-constructive critical here, I fully admit I haven't tried Om/React, just looked at your blog post about it. So what am I missing?
Using clojure data syntax instead of SGML-like syntax doesn’t make the language any more or less “declarative”. Assuming you use the same features in your templates, the clojure version is precisely as declarative as whatever other template language.
However, if you use the clojurescript version [or in standard React, the javascript- or coffeescript-looking version], then you suddenly have a bunch of potential extra features which in some cases are invaluable. (Or you can deliberately ignore those if you prefer.)
When you say “declarative” I think you might really just mean “familiar for html experts”. But most html expert should be able to learn the new syntax quite easily, since the relevant parts are less verbose than html, quite regular and straightforward, and semantically equivalent.
If you feel like putting your templates in separate files from your logic, or writing them using an SGML-like syntax, that’s pretty trivial to do in any of these environments.
Sounds like I need to give it a try, thanks for the feedback!
Hopefully not!
Why don't you give React a whirl and try not to force Angular thinking on to the React model. Shouldn't take more than an hour or two of investment to make a small toy app to experiment with.
I can't see that word without thinking of Cloaca. Cloaca. If you don't know what it is, you should. Cloaca.
Same here. Perhaps it's my exceptionally wry (and inappropriate sense of humor), but I rather wish it were cloaca. Just imagine the logo opportunities!
A startled pigeon, looking over its wing, tail up in the air, clearly exposing its backside...
...this is why I'd never get hired as a marketer or designer, never mind the fact I'm no artist.
I never thought that I would need this at Hacker News. A nsfw warning would suffice.
Ha ha! Oh wow! I just ran a google image search to see what you were talking about...
Knowing what a cloaca is beforehand, and then searching for it anyway on Google produces some truly curious results. I was trying to mentally prepare myself for what I may be about to see, because I couldn't imagine what might be on the other side, that would prompt your reaction. The only thing I could think of was some bizarre new form of bestiality that lurks in the shadows of taboo obscurity.
It turns out that most of the images are of obvious medical or scientific origin. I don't even know why pictures of humans show up in the search. I saw lots of pictures of various reptile junk which was totally expected, and none of it was being unceremoniously violated by unscrupulous human beings, so thank god for that!
Apparently there's a medical condition, "Persistent Cloaca Perineum", which is frequently misdiagnosed as "Imperforate Anus with Rectovaginal Fistula." The pictures that depict the condition are mostly de-identified newborn infants, and they originate from edu domains, but in a google search without proper context, they're kind of unexpected. I guess you learn something new every day...
My mother language is Spanish, and to be honest the first time i read the name i was thinking the word "cloth" or "coat" instead "cloaca".
Beware: you might be understanding cloaca as sewer (alcantarilla).
They mean THIS cloaca: https://en.wikipedia.org/wiki/Cloaca
LOL!
React is nice. I've created a simple library that shares same core concept - map DOM to Javascript objects. The difference is my lib uses Javascript standard data type, array, to represent tag, and hash(or object) to represent attributes, and strings for text contents. With a few tricks, I got a very powerful library - http://github.com/gcao/T.js. You can see an example written in CoffeeScript here
I wish github had better syntax highlighting for Clojure. Different colors for matching parentheses.
Here is that: https://news.ycombinator.com/item?id=7043299
IMHO, This look more easy to read than OM
Agreed. I'm so much more into the hiccup style tree building. This looks like something I can get into tonight. David is great but he prefers his code a little mysterious.
You can use Hiccup style with Om via sablono if you like via http://github.com/r0man/sablono. Om will never dictate nor provide an alternate syntax layer as everyone will want something different. I personally don't care for Hiccup.
More importantly, Cloact is much closer to the React model while Om diverges quite a bit because we're interested in enabling patterns that are more difficult otherwise, trivial complete UI state rewind on exceptions/errors, trivial undo, and more powerful operations on the applicate state history oriented at interactive debugging and development.
Of course these values might not interest you and you just want a simple direct mapping onto React. Then Cloact looks awesome! :)
Thanks, again :)
Yes, exactly, Cloact tries to stay really close to plain React. But since it allows you to separate data from rendering, undo should be quite trivial to implement (if you keep all your application data in a single cloact/atom)...
Yep sounds right to me. The other reason I did Om the way I did was to keep the door open for more React optimizations that Om can drive which are more work if you remain close to the React model - particularly only reconciling the specific children that changed in a list instead of iterating over them like React does.
One thing I can't figure out is why they need to be cloact/atoms and not just regular atoms. Is it because cloact/atoms are observable?
In a way. Using regular atoms you can only get a callback when they are modified, but not when they are deref'ed.
You could still use regular atoms, though, with some extend-type magic. But then you risk messing with non-Cloact code in horrible ways...
Undo is like half of what I want out of a reactive cljs lib! You sly devil you, I guess I'll keep watching both projects.
I think the hiccup style is a bit dangerous myself. It's great for a one-man show, or a situation where everyone who would ever have to touch the HTML is a developer, but personally I find it's a pain in my ass when it's my problem when someone else wants to insert an element into the DOM.
How does this all work with non-inlined event handlers? I see a lot of on-click, on-change going on in these examples.
React inlines event handlers since it manages them through it's virtual event system.
For more information on why react breaks preconceived notions of best practices I recommend checking out http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
Sorry for the noob question, but: does this take the place of Hiccup? Or, would one use both at the same time?
Firstly, Hiccup is Clojure (so basically server only). Cloact is ClojureScript, that compiles to javascript (so browser, node.js, etc).
Secondly, Hiccup produces strings. Cloact typically creates DOM elements, through React, that change every time a component rendered. But it can also produce an HTML string using the same data, to pre-render a page on the server using node.js.
Hiccup is for going html->string
This library goes from html->React data structure
The React.js system then is responsible for pushing it into the DOM, which it can often do in a way that's more performant than using a string intermediary (by computing deltas)
That's the short of it- The other part is that React is mainly a client-side technology whereas Hiccup is mainly used on the server (though these lines are blurry)
As danh and drcode said, Hiccup is basically edn->text and server side only but there are a number of implementations of the same concept in ClojureScript:
https://github.com/teropa/hiccups - Basically a straight port of hiccup to ClojureScript.
https://github.com/ibdknox/crate - Returns dom nodes instead of strings.
https://github.com/lynaghk/singult - Works in Clojure or ClojureScript and offers live merging of nodes into the dom.
https://github.com/Prismatic/dommy - Dommy is more than just templating but offers a hiccup style templating language too.
And I'm sure there are others.
Wow this looks like an awesome little lib. I love stuff like this.
Cloact: unfortunate name.
I had the same thought. It's a bit too close to cloaca. (But as software, it's an awesome idea!)
What about: "Clojir" - (ClojureScript Interface for React)
“Reajure” might be better. Halfway between “reassure” and “erasure”.
Leiningen will actually complain with this message if you try to make a project name that is too 'punny':
edit: this did not stop me from starting such a project https://github.com/tomjakubowski/dujureSorry, names such as clojure or *jure are not allowed. If you intend to use this name ironically, please set the LEIN_IRONIC_JURE environment variable and try again.Hah, that’s delightful! And a good lint rule besides. The Haskell world has a disproportionate number of packages whose names begin with H. Apparently my own joke wasn’t appreciated, though. :(
"reajure" sounds like it is about asking for something to be done twice ("re-" + "adjure".)
I like Clojact
I like it but for all the wrong reasons.