This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-25
Channels
- # announcements (2)
- # architecture (7)
- # aws (1)
- # babashka (105)
- # beginners (88)
- # braveandtrue (2)
- # calva (9)
- # cider (18)
- # cljs-dev (265)
- # cljsrn (22)
- # clojure (138)
- # clojure-argentina (3)
- # clojure-austin (1)
- # clojure-france (14)
- # clojure-italy (6)
- # clojure-uk (8)
- # clojurescript (283)
- # community-development (4)
- # conjure (11)
- # datomic (43)
- # docker (12)
- # duct (16)
- # emacs (1)
- # figwheel (1)
- # figwheel-main (27)
- # fulcro (10)
- # graalvm (6)
- # kaocha (4)
- # malli (9)
- # off-topic (13)
- # rdf (2)
- # reagent (12)
- # shadow-cljs (86)
- # spacemacs (1)
- # vrac (1)
Anyone getting exceptions with latest pathom + npx shadow-cljs server
? (just trying out 2.3.0-alpha6
)
Unable to resolve spec: :com.wsscode.pathom.connect/io-map
Just checked, seems to be an issue with the new alpha in general…
Some more digging it seems like a bad interaction with guardrails "0.0.12"
? 0.0.11
seems to be ok, I don’t know the ecosystem enough to know if this is a guardrails issue or a pathom one… Ok, I’m just going to revert… Now shadow’s stopped reloading…@lilactown not in any constructive way: that would indicate you wwant the same info in more than one place in the db, which is not normalization.
gotcha. how would one handle indexing on multiple attributes, e.g. a :account/id
and :account/email
?
@lilactown you can use :account/id
as the ident key, and have an additional index in app-state called :email->account-id
(top level) and populate it like so {"
and write some helpers that compute/update that index whenever you modify account data
@lilactown I would ask you to consider if you really need such an index: have you proven that doing a linear search of the account/id table is too slow for your use-case?
if it proves to be the case that you do need an index, there are many other considerations…the primary one being what was just mentioned: keeping it up-to-date, which can be a bit of overhead in itself (thus the reason Fulcro doesn’t encourage or implement such a thing itself…too many app-specific considerations)