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 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.
