This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-06
Channels
- # announcements (18)
- # asami (3)
- # aws (10)
- # babashka (47)
- # beginners (343)
- # calva (36)
- # cider (4)
- # clojure (66)
- # clojure-europe (9)
- # clojure-nl (3)
- # clojure-uk (23)
- # clojurescript (30)
- # community-development (69)
- # conjure (1)
- # eastwood (9)
- # events (7)
- # fulcro (81)
- # graalvm (1)
- # malli (5)
- # meander (1)
- # off-topic (41)
- # pathom (15)
- # rdf (1)
- # reitit (6)
- # sci (57)
- # shadow-cljs (18)
- # spacemacs (4)
- # startup-in-a-month (1)
- # testing (2)
- # vim (1)
@alandipert: Just wanted to say using a graph database for UI stuff makes a lot of sense. Especially if you can do subscriptions to propogate changes. IIRC fulcro3 does this, predated perhaps by om.next; but as I understand it fulcro associates react components with the queries to get their data directly. Also not just useful for UIs, I think christophe grande did a good summary of the problem in his zeno and the tar pit talk: https://skillsmatter.com/skillscasts/12820-keynote-zeno-and-the-tar-pit (you need to sign in to watch)
i found a few others, https://awardwinningfjords.com/2017/09/26/programming-with-facts.html, https://github.com/arachne-framework/factui, https://github.com/CoNarrative/precept, https://www.npmjs.com/package/@thi.ng/rstream-query
i think my view differs from these in that i suspect you don't want/need react when your changes are well-defined at the data level, but i have yet to prototype and see