Just to be sure I get it right... What I do now, with datascript is also 'one
way': all events are put on an core/async channel (well, publisher, actually).
The subscribers change datascript-values. Any changes in the database trigger
an update of the view:
(defonce init (fn []
(ds/listen! conn (fn [tx-report]
(rum/request-render root)))))
That's where should-update comes in handy: I don't have to keep track of all
components that have to be updated by changing one value: I let the components
decide themselves. It's pretty easy when reading datascript db values, but I'm
still figuring out how to do it with datascript queries.
Now, with the rules engine, it would be pretty similar (well, at least,
according to my mind :p): alle events are published and a subscriber adds the
facts to the rules engine. A fire-rules function would be something similar to
my 'trigger an update of the view'. The subsequent actions are basically
'update component'-actions? Meaning I'd write something like, for each
component:
(def component ...) ; possibly using hippo-style-something?
(defrule component-rule
[query result changed] ; this would look like 'should-update'
=>
(update component)) ; and do other stuff, e.g. add 'fact' to undo-list
(... which might be put in a function/macro)
D'you have any (very) basic examples? I feel like experimenting a little with
it :). I don't see the 'query result changed'-function yet, but I'm lacking
some clara knowledge so far... It'll probably be something with storing the
components previous state. Well, time get down to it.
Cool stuff! qsys
Op maandag 20 april 2015 23:56:56 UTC+2 schreef Alan Moore:
> On Mon, Apr 20, 2015 at 1:45 PM, Kurt Sys <kurt...@gmail.com> wrote:
> The basic stuff I need is really very similar. What I like about react, is
> not the dom diffing as such, the 'should-update' mixin. This really can make
> things way easier. It doesn't play as nice as I thought it to be between rum
> and datascript queries, but it'll work. Datascript queries are really
> amazingly powerful to me. I use them really a lot, and full dom diffing might
> be pretty, or more, expensive compared to a 'should-update'.
>
>
>
> That said, I had been looking to clara before (for another kind of project),
> but I pretty much like the idea of using it as 'database/query
> engine'-someting. Would you implement something like the should-update on
> component basis as well. I'm really very interested in your wrapper/library
> and how it would work out.
>
>
>
> The nice thing about Clara (and rule engines in general) is that you can
> declare that certain functions (RHS) are to be called when a set of
> conditions/queries (LHS) over your data evaluate truthfully. There is no need
> for "should-update" polling, it is more don't call us, we will call you -
> control is inverted. When a user or server event happens the handler code
> inserts the event data into the engine and then calls the fire-rules function
> to trigger subsequent actions based on the rule conditions.
>
>
> Clara does truth maintenance which is an awesome feature but in my use case I
> have to work around it slightly to accommodate transient facts/events. Not a
> big deal just something to keep in mind when first understanding how it works.
>
>
>
> I don't really see there being a need for a wrapper around Clara - you can
> use it as-is. I'm just trying to figure out the best way to integrate it in
> the client-side context. It was built with a particular set of use cases in
> mind that don't always match up with my experience with other rule engines
> that are more "mutation" oriented. Clara's rule engine is a value in the same
> way that Datomic's database is a value. This is super powerful but that means
> you need to organize your code slightly to take this into account.
>
>
> 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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
