This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-10
Channels
- # announcements (1)
- # babashka (18)
- # beginners (122)
- # calva (18)
- # cider (3)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (102)
- # clojure-europe (15)
- # clojure-france (2)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (3)
- # clojure-uk (8)
- # clojurescript (46)
- # clojureverse-ops (5)
- # code-reviews (1)
- # conjure (2)
- # cursive (15)
- # datalog (13)
- # datomic (18)
- # emacs (4)
- # fulcro (8)
- # helix (8)
- # instaparse (1)
- # introduce-yourself (2)
- # jobs (4)
- # leiningen (23)
- # lsp (26)
- # malli (21)
- # off-topic (34)
- # pedestal (21)
- # polylith (6)
- # reitit (5)
- # remote-jobs (3)
- # schema (1)
- # sci (8)
- # shadow-cljs (8)
- # spacemacs (3)
- # sql (30)
- # testing (31)
- # tools-deps (21)
- # vim (25)
- # xtdb (8)
what are the options for (reagent-)reactive datascript on the frontend? posh (https://github.com/denistakeda/posh) seems unmaintained.
I think homebase is just a wrapper around datascript and reagent and exported for JS applications
I say "amazing" as in, most of these use datascript and IME the performance of datascript is not good enough for most UI apps I've worked on. posh tries to address this by doing some complicated diffing internally to avoid triggering every query on change, but it doesn't end up being as robust as one would want and still can end up doing a lot of expensive calculations on every db transaction
homebase doesn't support pull queries, so it was out of the question. The project already uses (re-)posh, so will start by fixing posh, it cureently fails on tracking reverse relations.
looking at the posh internals, it looks smart, the impl could be optimized a lot. If I understand it correctly, all the queries will register their own matchers, having 100 queries will cause 100x matching, which doesn't scale.
matchers could be grouped by their common parts, kinda like trie, would make it scale better.