Skip to content

Instantly share code, notes, and snippets.

@swannodette
Last active January 9, 2021 16:09
Show Gist options
  • Save swannodette/d42c8864ecd51d71bc40 to your computer and use it in GitHub Desktop.
Save swannodette/d42c8864ecd51d71bc40 to your computer and use it in GitHub Desktop.
(defui Artist
static IQuery
(query [cl _]
[:db/id :artist/name])
Object
(render [{:keys [props]}]
(dom/div nil (:artist/name props))))
(defui ArtistList
static IQuery
(query [cl _]
(query Artist nil))
Object
(render [{:keys [props]}]
(apply dom/ul nil
(map #(artist %) props))))
(defui Track
static IQuery
(query [cl _]
[:track/name {:track/artists (query Artistlist nil)}])
Object
(render [{:keys [props]}]
(dom/div nil
(dom/h4 nil (:track/name props))
(artist-list (:track/artists props)))))
@kahunamoore
Copy link

Interesting. I like it.

If you squint real hard you might mistake (defui) with (defrule), (query) with the LHS, (render) as the RHS of a Clara rule. I'm trying to glue that to React in the simplest way possible. Needs more endless pool time :-)

@jespera
Copy link

jespera commented Apr 13, 2015

@kahunamoore: using a (production) rule system to specify UIs seems like an interesting approach. The truth maintenance of such systems would be beneficial it seems: E.g. one would only need to specify under which conditions an input is enabled and the once said conditions are no longer satisfied, the input would be disabled. Similarly, if another input should be disabled if some other input is also disabled, the truth maintenance would take care of all that! Do you have some more thoughts on a "RETE-enabled UI specification" somewhere? (@Swanodette: sry if this is not the right place for what I wrote)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment