This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-02
Channels
- # announcements (2)
- # beginners (69)
- # boot (1)
- # cider (35)
- # clara (1)
- # cljs-dev (1)
- # clojure (40)
- # clojure-spec (11)
- # clojure-uk (8)
- # clojurescript (9)
- # cursive (1)
- # datomic (5)
- # figwheel-main (25)
- # fulcro (64)
- # jobs (2)
- # jukebox (1)
- # kaocha (3)
- # off-topic (7)
- # pathom (39)
- # planck (5)
- # random (1)
- # re-frame (11)
- # reagent (8)
- # shadow-cljs (58)
- # test-check (41)
- # vim (13)
@wilkerlucio more of a Pathom question so I’ll post it here: in my application I’ve found myself using :current-user
as a root for pretty much everything, since all my data is user-dependent. Is that sensible?
So I have html5 routing set up, and on route change I load some query rooted at :current-user
yup, IMO you should avoid simple keywords entirely
because at some point systems will connect, if they both use simple keywords they can't talk without ambiguity
thats a good topic for a documentation section, but yes, you app/company should prefix everything with its name
so would be :my-app/current-user
:my-app.user/name
...
simple keywords are only good enough on demos, which is a problem because people copy from demos, heh
@hmaurer also having qualified keywords allow you to get more data around it, because they are context free information, spec been the major example case for extracting more info about the keywords thenselves
@wilkerlucio yeah that makes perfect sense, although in my current project at some point I over-qualified keywords I think. I started qualifying them by module as well, e.g. :my-app.my-module.some-entity/some-property
and they got very long. Perhaps the app prefix is enough
yeah, remembering that what matters is the name, the namespace is just a qualifier for the name to avoid collision
some people can argue using domain names (like Java does) but in practice I see project name been enough
for example, if we make a bunch of resolvers for youtube
, that will hardly crash with anything else (unless someone is doing on purpose, not accidental)
Switching over here, as this is more pathom specific. For pathom, I see the most usefulness to manage multiple sources of data that do not implement a graphQL-like attribute level of querying. With Datomic, as we have pull syntax, we can pass most of Fulcro queries directly to a single resolver that hands of the query to d/pull
My question is: Given Datomic has pull, what is a good way to combine resolvers given we already have arbitrary query expressions in the db?
(I know in that expressing my API with pathom is the way to go, as I can later expose a graphQL API to talk to my data)
@pvillegas12 I'm afraid I can't help much with that because I lack experience using datomic with pathom, for what I see people tend to avoid exposing they whole datomic tree via pull, if you have that concern in mind then breaking it down and controlling whats acessible ends up been an asset, but if you are in a situation where uncontrolled access is ok (maybe something internal dev tool) then I think will be easier to use datomic entities instead of pull, maybe you will need a custom reader, but from that you could expose everything and combine with resolvers for computed values
about the graphql out, that's something I want to do, but its not there yet, pathom can consume graphql apis, but not expose it
why would they avoid exposing the whole tree?
because the UI has direct access to it, so it could leak private data, since all connections would be exposed
you mean when you introspect it?
or just protected data in general, delegating all to datomic pull gives you no control, so you dont want your end user to have direct access to it
I was thinking more of datomic pull + policy logic in the resolver env
Let’s see if I understand this, you’re saying create a resolver that does a d/pull
and then do a select-keys
without the private.data/
namespace for example?
correct, that's the point, you have to be in the middle, you cant blindly send it over, but I'm just speculating possibilities that you could try, as I told I have no experience using datomic with pathom
yeah, this conversation is useful either way for me 😄
yes, but think about nested queries, then can get complicated to "select-keys"
correct
so what I see people doing is providing level 0 and level 1 nesting on their pull patterns
like: [:user/name {:user/addresses [:address/id]}]
so no more than 1 nesting level, and leave the "ids" in place so other resolvers will pick up an continue
with this pattern each resolver level have control over "one resource" kind, and you can split more depending on how much control you want to have
Got it, so the resolver specifies which keys you want to expose publicly essentially