This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-21
Channels
- # architecture (9)
- # beginners (192)
- # boot (1)
- # bristol-clojurians (2)
- # cider (213)
- # cljs-dev (10)
- # clojure (195)
- # clojure-art (2)
- # clojure-austin (3)
- # clojure-belgium (4)
- # clojure-dev (4)
- # clojure-dusseldorf (1)
- # clojure-gamedev (9)
- # clojure-greece (21)
- # clojure-italy (27)
- # clojure-losangeles (2)
- # clojure-russia (1)
- # clojure-seattle-old (2)
- # clojure-serbia (1)
- # clojure-spec (114)
- # clojure-uk (136)
- # clojured (2)
- # clojurescript (100)
- # community-development (19)
- # core-async (12)
- # cursive (7)
- # duct (1)
- # figwheel (7)
- # fulcro (96)
- # hoplon (4)
- # jobs (2)
- # lein-figwheel (28)
- # leiningen (2)
- # luminus (14)
- # lumo (3)
- # off-topic (11)
- # om-next (2)
- # pedestal (10)
- # planck (11)
- # portkey (2)
- # proton (1)
- # protorepl (19)
- # re-frame (27)
- # reagent (12)
- # shadow-cljs (82)
- # spacemacs (42)
- # specter (15)
- # sql (3)
in a component’s query, is there a way of expressing “take this part of the query, and plug it into this ident elsewhere in the query and use it to do a lookup for some properties”? basically an ident query with a parameter from the query itself as the id of the ident like:
{:query [:thing-id
{[:other-thing/by-id :thing-id] [:thing/name]}]}
afaict, that query ends up resolving to something like (get-in state [:other-thing/by-id :thing-id])
as opposed to (get-in state [:other-thing/by-id 123])
@mss maybe you meant to write:
{:query [:thing-id
{[:other-thing/by-id :thing-id] [:thing/name]]}}
?usually you don't do ident queries from identities
on the server parser, you give a name of the association of the data
and then though normalization the idents are filled on the client side
when you say “do ident queries from identities”, could you expand on that a little more? sorry just not quite exactly what you’re getting at
@mss ah, sorry, I might had only understood your question
no worries. I guess the crux of what I’m trying to do is a parameterized ident + property lookups at that ident based on some other property in the query. feels insane but maybe that’s a thing?
maybe you are looking for this? https://wilkerlucio.github.io/pathom-book/DevelopersGuide.html#_placeholders
humm, you mean like, getting and account-id and using that value to look up some other identity on the same query level?
specifically in my case I have a prop passed in from a router, and want to do lookups based on that prop
that can be a pain over time for you, what we usually do instead is make this kind of integration on the server side
so instead of querying identities in sub-queries, you give a name to that relation, and you server is responsible for implementing it
so, instead of:
[{:app/current-user
[:user/account-id
{[:account/by-id :user/account-id]
[:account/account-number]}]}]
you would use:
[{:app/current-user
[:user/account-id
{:user/account [:account/account-number]}]}]
@mss, this way you encode the relationship in a name (`:user/account` on this case), and can go crazy about it on the server (like, you might need to get an attribute and use to query a different server to read some id to make a relationship, etc...)
makes sense?
absolutely that makes a ton of sense. unfortunately afaict my case is a little weirder as I’m trying to resolve a query like that based on a route param from my router. so router toggles component with a value for a certain route param, and I need to do some lookups based on that. feels whacky and like I might be doing things incorrectly
obv I can just pull the whole table into my component and do a lookup inside of it based on the route param passed in. but that feels insane
usually when you have routes, you are loading from a given route (not send the entire union)
so you should not need any rounting on that sense on the server
the client route is defined usually by the entity key, so you just need the correct ident there
what are you trying to make?
@mss getting late here, have to go to the bed, but let's continue this tomorrow, I would like to understand what is your case
@mss For your usecase I usually create a defsc with the ident from params and use get-query. As far as I know it's a valid pattern when you need to give the df/load a query that does not match the ui, should work for that usecase also.
@mss a query by ident is literal. prop names are not variables. There are query parameters (see set-query!
) where you can rewrite the query over time for a component to use a specific thing for part of the query with ?varname
, and then use set-query!
to set the param :varname
to any value.
If you’re trying to use a bit of app state for this task, then you don’t want an ident in your query, you want the ident in your state. Any join that is normalized is a graph edge that can point to any entity of the sub-type. Typically what you do is write a simple join, and modify that prop in app state to point to your desired target.
@tony.kay is it a valid pattern to have a component just for getting stuff from the db (no render or mutations on it) and using the data in the parent ? or am I asking for trouble ?
why not just treat it as opaque data if there is nothing for a subcomponent to do with it?
in either case, you’re not really asking for trouble as long as you follow the general composition rules. You could join in a component’s query, use the data, and never call that component to render it.
but that’s different: (defsc X [t p] {:query (fn [] (prim/get-query Y))})
is a no-no
as long as you compose the query with the rules, it’s fine to have a query/ident-only component for server (or client) queries
@tony.kay @wilkerlucio I’m seeing Bad method signature in protocol implementation, f.network/FulcroRemoteI does not declare method called network-behavior
after the newest fulcro SNAPSHOT. Do I have some stale packages?
[fulcrologic/fulcro "2.3.0-SNAPSHOT"]
[fulcrologic/fulcro-inspect "2.0.0-alpha6-SNAPSHOT"]
In fulcro.inspect.core
: Use of undeclared Var fulcro.client.network/network-behavior
Wasn't official Api yet, and I have plans to deal with that concern differently in the future
hello everyone, just to notify you about another Fulcro app: https://dataportal.cmcc.it
@U15D43HU7 did you use a UI library or make everything from scratch?
looks pretty good by the way!
did you use the cljsjs version?
of SemanticUI
Poor Internet here this morning so it is continuously 'loading'. Is there a GitHub site?
@U15D43HU7 no worries, thanks for the reply!
@U0D5RN0S1 unfortunately it’s not public, sorry
and take the chance to thanks many of you in this channel for the kindness and the great help I received during development
@wilkerlucio I'm wondering if a simple pathom plugin can do this: keyword aliases. Eg: {:person/pet [:db/id :pet/name]}
will end up in walkable sql builder as {:person/pet [:pet/id :pet/name]}
but the keyword in the result returned to client remain :db/id
instead of :pet/id
?
btw, the latest source code for walkable
is here: https://github.com/walkable-server/walkable
it comes with a handy duct setup to explore walkable features
@wilkerlucio never mind. it's more straightforward than I thought
@myguidingstar I'm in a meeting right now, but I was going to write you an example
a reader can solve that I think
you can look at ::p/path
to get the :person/pet
while reading :db/id
how did you solved it?
I manually replace :db/id
with :pet/id
then rename-keys
the sql result
I guess the problem with ::p/path is that :pet/id
is not there for :db/id
I think a reader might be easier, let me write one for you in a bit
thanks 🙂
@myguidingstar ok, got it, see what you think about this impl:
(defn id-convert-reader [{:keys [ast]
::p/keys [path]
:as env}]
(if (= :db/id (:key ast))
(let [parent-join (-> path rseq second)
new-key (keyword (name parent-join) "id")]
(p/entity-attr! env new-key))
::p/continue))
(def parser (p/parser {}))
(parser {::p/reader [id-convert-reader p/map-reader]
::p/entity {:person/name "User"
:person/pet {:pet/id 123 :pet/name "Rex"}}}
[{:person/pet [:db/id :pet/name]}])
@wilkerlucio the problem with the above impl is that p/entity-attr!
assumes new-key
already exists in ::p/entity which is not the case because the sql query buider ignores :db/id (because it thinks that's an invalid keyword)
the p/entity-attr!
does another query for that attribute, so if you have a reader that can parse it, it should work
I was expecting a kind of alias plugin that works seemlessly so the next plugin in the plugin chain don't need to be aware of any aliases at all
in the case of walkable sql, it should never have to deal with :db/id
@myguidingstar doesn't the reader serve as the same? a reader is pretty much like a read plugin, the read plugin just have more override and can wrp
but on this case, you could use it only once, at get the benefits for anything (it looks at the parent path, so it should always be "correct")
with that said, could you explain why are you doing the translation? I would like to understand better what is your intention, because usually I would recommend don't, the power on the keywords is because they work "as is", renaming then can generate confusion IMO