This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-17
Channels
- # beginners (42)
- # cider (1)
- # cljs-dev (20)
- # clojure (73)
- # clojure-italy (8)
- # clojure-nl (53)
- # clojure-spec (11)
- # clojure-uk (88)
- # clojurescript (170)
- # clojutre (6)
- # core-async (26)
- # css (2)
- # cursive (13)
- # data-science (10)
- # datomic (15)
- # editors (3)
- # figwheel (28)
- # figwheel-main (67)
- # fulcro (57)
- # graphql (2)
- # immutant (2)
- # jobs (1)
- # jvm (4)
- # lein-figwheel (3)
- # leiningen (1)
- # off-topic (5)
- # pedestal (28)
- # re-frame (86)
- # reagent (18)
- # reitit (8)
- # ring (3)
- # ring-swagger (2)
- # shadow-cljs (78)
- # spacemacs (10)
- # specter (12)
- # tools-deps (32)
- # vim (3)
@montanonic there is also initLocalState which goes into component-local state (React) if that’s what you’re looking for.
Haha, I was just literally looking at that now
The function you give there can be used identically to a react class constructor, other than what you return becomes the local state
but it is called once and only once during component construction, so anything else you’d normally do in a React class constructor can go there
Which means I can trigger mutations on the root from there, supposedly, too
Yes, definitely, it hadn't been clear to me earlier
they are different things…one is managed by React ON the component instance, the other is database of Fulcro
If you want to trigger “ensure this is such-and-such” for the state database of the app, then you can run a mutation via componentDidMount
One other question on this: how can I fetch the local state
looking at it now; okay, totally makes sense, I was confusing myself with get-initial-state, which is entirely different
Thanks Tony
sure…might be a good idea to watch some of the YouTube videos…I try to be very concise in them, and a lot of people find them useful when getting started
I have! They are excellent, could probably use a revisit though since internalizing these things takes a bit of time.
@wilkerlucio is it possible to have autocomplete keywords in OgE without using pathom connect?
the auto-complete feature depends directly from the connect indexes to work
@myguidingstar I would love to see walkable with a connect integrated version, for those cases where we have some external source of schema (like SQL, or GraphQL) you can do a more advanced integration where you generate the indexes instead of hand writing it, I would be glad to help you get there if you like to go on this direction, there is some work done for GraphQL, the idea is very similar
@wilkerlucio thanks a lot. I'm interested in such integration, too and I've read pathom connect doc recently
however walkable took a bit different approach, I'm still thinking of a way to make it work the pathom connect way
I should do some experiments first. I'll let you know then
@myguidingstar it shouldn't change much about walkable code, the extra work for connect is more about instructing the engine when the walkable resolver should be called (which attributes it should respond to), from there you can trigger the resolver and use parent-query for defining the query to run
I'm looking at the function p.connect.graphql/build-query's unit test
what's it input and output?
input is environment and entity, output is the query that is going to be sent to GraphQL
more details about the output please?
its a subquery, pathom will be processing a single attribute, this looks in the parent and build a query to leverage sibling elements that can be fetched on the same request
by query I mean a regular query, like [:foo :bar]
thanks
from the source code, that function seems to miss placeholders?
yeah, placeholders still not supported there, but I got recently a case where I might need to support then, so I should work on that soon
in walkable I use clojure zipper to find attributes nested in placeholder https://github.com/walkable-server/walkable/blob/master/src/walkable/sql_query_builder.cljc#L189-L231
regarding walkable - connect integration, should everything have a place in indexes?
say I have the query ::top-products (or [{::top-products [:product/id :product/name :product/price]}]) that return the result from sql query select id, name, price from "product"
what should the ::pc/input and ::pc/output of its resolver in the index be?
the way to go is defining a prefix for your integration, so when you generate the index you prefix the things with that
so for example, if you call you db my-app, you can use the my-app prefix
so for the table product, it would be :my-app.product/id :my-app.project/name ...
this allows for many implemenations live together, and on the index you point those to your resolver
@wilkerlucio what about ::pc/input and ::pc/output?
those are helpers to define a la cart, you don't need it on the custom implemetantion
they are only used when you add something new to the index, but since you are going to generate the index separated, this doesn't matter, you can just don't provide those on the resolver data
does those ::pc/input and output help with caching?
also, what exactly is cached in connect?
usually we cache by resolver/input, but on those adv integrations that will not work, so you must disable cache for your resolver (set ::pc/cache? false on the resovler)
by default it caches during the request, if you ask the same resolver with the same input, it will be cached
but in this dynamic scenario your result is also based on the subquery/env, so the caching would not work for that
what is in ::pc/input and ::pc/output don't matter in the end, they are helpers to construct the index, what matters is what will be in ::pc/index-oir (for parsing) and ::pc/index-io (for auto-complete)
ah, I see
I suggest checking this query builder for graphql, walkable can use something similar: https://github.com/wilkerlucio/pathom/blob/http-drivers/src/com/wsscode/pathom/connect/graphql.cljc#L280-L290