Absolutely, thank you! More time to work on other stuff, yay :-) Native ClojureScript FTW! Wrappers are convenient and good if you need to play nice with existing frameworks (looking at you React) but otherwise they seem suboptimal.
Thanks for the library Julien and a hat tip to Prismatic for dommy. Alan -- *"Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now."* - *Goethe* On Apr 18, 2015, at 11:25 AM, Julien Eluard <[email protected]> wrote: Hi Alan, you might be interested by the latest release of the hipo [1] library which provides reconciliation (à la react) [2] of live DOM nodes. It is essentially a native ClojureScript 'virtual-dom' implementation using hiccup vectors as syntax. Cheers, Julien [1] https://github.com/jeluard/hipo [2] https://github.com/jeluard/hipo#reconciliation Le samedi 18 avril 2015 14:20:14 UTC-3, Alan Moore a écrit : Sorry for the delayed response. Yes, I stand corrected, I evaluated just about every front end library there is for ClojureScript and some of the names are starting to get confusing to my age addled brain (react, reagent, freactive, re-frame, etc..) I really just want the DOM diffing from React and don't need any of the other stuff. I'm considering making a ClojureScript wrapper for: https://github.com/Matt-Esch/virtual-dom My goal is to write most of the front end logic using rules (Clara is the best candidate ATM) so the view portion needs to be as simple as possible for the rules to manipulate the DOM. The rule engine provides all the data reactivity I need - any data (normal clojure data) you put into it is automatically pattern matched against the rules, including unification/relationships with existing data - as defined by your rules. Here is the general idea: Model: Data inserted into the rule engine's working memory View: DOM/React/Rum/vdom Controller: Rules in the engine It is reactive in the sense that inserting data/facts/events (from server or user/view events) into the engine triggers rules to fire, those rules may then update the UI or the server, rinse and repeat. There is no "polling the data" for changes because the engine maintains a data structure (a Rete graph) that pattern matches against your data as you insert it, edge-triggered as it were... You can query the data stored in the engine using a defquery... which is like a defrule without a RHS. The goal for my app is to keep all the core app logic in the rules which makes them easily unit tested because the primary externalities are just data. Think of it as a reactive version of Datascript, at least that is how I see it. Also, in theory, Clara artifacts such as rulesets and sessions can be moved around a system as self contained units of logic giving you a lot of flexibility in how you organize (or re-organize) your architecture. According to Ryan Brush, the author of Clara, they deploy Clara in Hadoop jobs to great effect. Along the same lines, another experiment I want to look into is extending the core Clojure data protocols (ISeq, Iterable, etc.) to the Clara sessions so that, to the rest of the system, the session looks just like a regular Clojure data container... or something like that (e.g. conj == insert, etc.) I'm curious to hear how Rum works out for you. I think Rum and Quiescent are both excellent minimalist React wrappers. Om is awesome but is more than I need. If my experiments don't work out I may go back to it... TBD. If you like Datascript and Quiescent then you might want to check out: https://github.com/thegeez/clj-crud It is a really cool app template to get you started. I'll let you know how it goes, my app is still very much a work in progress. I'm currently working on converting the Clara codebase from crossovers to using reader conditionals so that is a bit of a diversion from the UI side of things. As with your project, this is one of many side projects for me. I need the day job to pay the bills... :-/ Take care. Alan -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/kCdOQzPNAug/unsubscribe. To unsubscribe from this group and all its topics, 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.
