Fork me on GitHub
#fulcro
<
2020-04-25
>
folcon12:04:29

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…

lilactown19:04:55

is it possible to have multiple idents for the same entity in fulcro?

tony.kay19:04:49

@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.

lilactown19:04:05

gotcha. how would one handle indexing on multiple attributes, e.g. a :account/id and :account/email?

currentoor20:04:24

@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 {"" [:account/id 1] ...}

currentoor20:04:57

and write some helpers that compute/update that index whenever you modify account data

tony.kay23:04:32

@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?

tony.kay23:04:51

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)

tony.kay23:04:34

If you really really need such an index, I’d add a watch on the state-atom and add logic that auto-generates/updates it based on the table itself changing (which is a very fast check since you can use identical? to do a ref compare)

tony.kay23:04:25

or you could carefully construct an API in front of the entities in question that you always use when working with them so that you can do targeted index maintenance over time…but that requires discipline and is easy to break