This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-28
Channels
- # beginners (79)
- # boot (24)
- # cider (5)
- # clara (5)
- # cljs-experience (5)
- # clojure (126)
- # clojure-greece (5)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-russia (1)
- # clojure-spec (21)
- # clojure-uk (31)
- # clojurescript (151)
- # community-development (20)
- # cursive (25)
- # datomic (24)
- # flambo (1)
- # fulcro (312)
- # graphql (10)
- # hoplon (20)
- # juxt (2)
- # keechma (6)
- # leiningen (7)
- # luminus (4)
- # om (4)
- # onyx (7)
- # parinfer (24)
- # protorepl (1)
- # re-frame (7)
- # reagent (13)
- # shadow-cljs (19)
- # spacemacs (14)
- # specter (14)
- # uncomplicate (22)
- # unrepl (1)
@tony thanks for opening the issue, I was trying to figure here first if it wasn't some mistake of mine, I'll try to pinpoint the problem exactly, I'm using custom networks so this might be affecting the result too, I'll let you know as soon as I have some time to debug it properly
Fulcro-sql update: 0.1.0-SNAPSHOT on clojars. Now supports recursive queries (`...` and n); however, n
does not actually limit, and there is no loop detection. So it will not work for you yet if your data goes in circles.
OK, that wasn’t so hard. Update pushed again. Now has recursion limit and loop detection support on 0.1.0-SNAPSHOT.
I also added support for bi-directional transform multimethods for converting Om props to/from SQL props. That was an oversight on my part. I’m not enamored with it at the moment, I think @wilkerlucio suggestion that the schema should just support a function instead of a map is probably the way to go. I like the schema being pure data. Still thinking it over. The property transform functionality could therefore change, but that would have a minor impact.
Hey! We’re seeing an issue with df/load
. On a slow connection (limited to “slow 3g” in chrome), we have df/load
‘s being fired from componentDidMount
. With a slow connection the app state load markers get correctly placed and an entry is made in :ui/loading
but the network queue never tries to send the request. Setting :parallel false
resolves the issue. I’m tracking it down now but if anyone has any ideas it would be appreciated.
This only happens in advanced compilation
Noob question. Just can't seem to figure it out, missing something basic. 😞 I have a listing that I load from the db elements ident [article/by-id 1], and when I click on a link I want to open a modal that has ident: "modal/by-type article" and have the article details there (since the article is partially loaded) I am trying to have in the overlay query something like {:article (om/get-query ArticleDisplay)}
@gardnervickers Hm. Optimizations break it?
Yea, :advanced
. It’s super strange that it happens only when there’s a network delay.
Maybe a race condition getting the network send loop up I’m thinking
That fixes it for us
:parallel true
Ahh sorry about that.
They never happen
The request is never made
The load markers just stay in app state perpetually
The Network tab in chrome doesn’t show anything.
But weirder, we have a df/load
in our :started-callback
that hits the queue and that works correctly.
Yes it’s a child of a union
If that’s what you mean? Sorry I might not be following
https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/core.cljc#L239
Ahhhh would my union initial state not show up then?
Yea hmm I don’t think this is what we’re seeing but it does sound like a bug. This happens if we’re just calling df/refresh!
without any conditionals in componentDidMount
And the load markers are correctly placed in app state.
So, I’m going to push a change on that anyway…1.0.0-beta9-SNAPSHOT is on clojars with that reordered
Sure thing, thanks
so far so good. It doesn’t break things. There is no concurrency in the browser, so I don’t expect a race condition so much as a hard-to-reason-about code path. The atom has watches on it that trigger re-render, so some of the swapping that happens during startup could trigger renders.
That SNAPSHOT breaks my routing lib, there’s no app-root
for the reconciler passed to :app-started
callback.
And it does not solve our issue, thanks though I’ll keep looking.
pushed a new snapshot. The order is now after the merge of alt unions, but before callback
I’ll give that a shot
@gardnervickers That won’t fix it…let me try one more thing.
@tony.kay Looked a bit at the bootstrap example. Was doing it right actually, just was not careful and did assoc into [:modal/by-type :article]
instead of [:modal/by-type :article :article]
. 🙂
@gardnervickers I found something that looks fishy in networking. Try the latest beta9-SNAPSHOT with your adv opt
Thanks, will do
Hrm nothing changed
I can confirm that we’re not hitting real-send
at all
so, what I changed was the callback logic in networking. If the callback doesn’t trigger right, then it won’t unblock the send queue
this is the core async queue implementation: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/impl/application.cljc#L159
Hrm maybe I got the wrong snapshot version, that sounds like my problem
for each networking, there is a payload queue, and a response queue. The response-channel is what blocks from getting the next request. The callbacks in networking trigger an item to be placed on response-channel, which frees the processing to get the next item in queue
if you’re hung, then you’re either waiting on response-channel and nothing it posting to it, or the main queue is empty. The latter could be cause by 1. The code that places stuff on the queue (load) ran before the queue existed. 2. Something cleared the queue.
I’m pretty sure this is a core.async problem where we’re relying on something to finish before it actually does. When I step through with the debugger everything works correctly.
There’s only one thread…so I’m not sure how that’s possible. I have to take care of some stuff this afternoon. If you have any further insights I’ll be glad to try patches.
Anywhere (go ...)
is called without a corresponding take schedules the body for some time in the future.
(go (print 1))
(go (print 2))
(go (print 3))
can happen in any order.Thanks for you help, I’ll keep digging.
No the problem goes away with :parallel true
Thanks 😄
I see my query being placed on the relevant :send-queue
but the sequential processing loop never gets it.
I cannot seem to get ident loads to work
(load comp-or-app [:person/by-id 3] Person)
been wrangling this for 3 hours now and I always get Uncaught Error: No protocol method IMapEntry.-key defined for type cljs.core/PersistentArrayMap: {[:medlist-by-level "amp"] [:level :ui/selected {:items [:id :name :level]}]}
When loading by ID, what should the map I call the callback look like?
{[:person/by-id 3] {:name x :id y}} ?
or should it be {:person/by-id {3 {:name x :id y}}}
@roklenarcic The error you’re getting is unrelated to that load.
hm ok, but non-ident loads work fine
as do ident loads…they are all over the place in existing code…and your call looks fine
the stacktrace suggests it occurs when om.next tries to merge idents
ah, that’s better. OK, the shape of your server return value should be:
{ [:person/by-id 3] {:id 3 :name "boo"}}
ok I'll look into that
i'm not using the Person example verbatim
oh wait @roklenarcic I may have mis-spoken. The macros will wrap it for you all the way to the value
You’re in a parser, it will put the key back on the response…and the key was the ident
{:value person}
if using your own read emitter, or just person
if using the defquery-entity
macro.
the actual call is (df/load app [:medlist-by-level "amp"] MedList {:remote :rest :params {:filter "a"}})
an it's in :started-callback
MedList has ident [:medlist-by-level level]
and it returns data from a REST call, currently mocked to (ok {[:medlist-by-level "amp"] [:items [] :level "amp"]})
in my Network impl
(query [this] `[:level :ui/selected {:items ~(om/get-query MedListItem)}])
ok, I'll fix that
For clarity: results are always trees. A join can point to-one (a map) or two-many (a vector of maps).
hm, same error for (ok {[:medlist-by-level "amp"] {:items [] :level "amp"}})
so merge is trying to treat your vector like a map (since it isn’t a vector of maps), and when it does you get an error about it not having a method that is expected on maps
feel free to ask about those quicker than 3 hours 🙂 I appreciate not being hounded every 5 mins, but hate to see ppl waste that much time on something that a second pair of eyes can spot easily 🙂
the weird thing is.. why does the error talk about the query
rather than data returned
@tony.kay We tracked down the problem to the event handlers here
https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/network.cljc#L94-L95
Wrapping them in (do ...)
solves our issue. I’m not sure why that is though.
@gardnervickers ooops…shouldn’t that be in opposite order? Register for events before triggering send?
Ohh man yea
@roklenarcic any luck with clean build and reload with cleared cache?
We found this fixes our issue though
#(do (response-ok this xhrio ok))
I cannot believe that is a reliable fix. I pushed a reorder of those statements to beta9-snapshot on clojars
Trying that in my checkouts now
no luck, om.next/merge! is being called with this as query [({[:medlist-by-level "amp"] [:level :ui/selected {:items [:id :name :level]}]} {:filter "a"})]
seems to me that it has one pair of braces too many
@tony.kay question regarding multiple remotes, to send mutations to a custom remote we can use the different keys on the mutation map, is there a way to select which remote to use during a fetch/load
usage?
@tony.kay removing the (do ...
and putting the send after binding the event handlers resolves my issue as well.
@roklenarcic Ah…it is a bug, actually
{[:medlist-by-level "amp"] {:items [], :level "amp"}} is the value
yeah that query causes the following call down the line: (conj! transient-array-map a-list-of-1-vector)
yeah, what you have is right. merge-ident
isn’t handling the parameterized query correctly. I think this is an Om Next bug, but I want to check to make sure. We augment the merge pipeline
yeah that was the only difference between the sample and my code
@gardnervickers I’d call that the real bug/fix for that
Sweet thank you for your help
@wilkerlucio load
has a :remote
parameter, if that is what you’re asking
@gardnervickers thanks for tracking it down…not sure how that made it for two years without causing a problem.
humm, nice, I'm doing some experiments with multiple networks, I though I was going to have a lot to do, but seems the multiple remotes just have a lot of helpers on that 🙂
so let's say I have 3 lists with search inputs, currently they have idents [:medlist-by-level "amp"] [:medlist-by-level "vmp"] etc... how would you load the search without using ident load with filter as parameter?
@wilkerlucio multiple networks is used in serveral places in the demos and such. File uploads use a separate remote for doing progress reports, websockets are in the chat demo, and can be used in tandem with non-websocket remotes.
thanks for letting me know, seems a good place to look into
@roklenarcic So, it is not problem using parameters with ident loads…that is a bug that should get fixed. In terms of your actual question: I would be targeting a field instead of loading an entity. Your search results are not really related to an entity on the server. I’d have a UI component with a :search-results
field, do a (load :search/medlist MedListItem {:params {:filter "boo"} :target [:medlist-by-level "amp" :search-results]})
maybe include “amp” in your parameters, so you have a single keyword to worry about for what to ask the server
great 🙂
@tony.kay I'm going down with that UI bug, I got down to this line: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/impl/data_fetch.cljc#L402
when it gets here, the query contains the ui
part, but the output doesn't, adding the :not-found
marker at this point
which in turn removes it when merging the ident
I feel like there is some place where strip-ui
must be called, but it's not being
trying to figure where this is exactly, just dumping here to see if it clicks something for you
now that I think about it, the strip should really be earlier in the chain. I think it is all the way down at the send. That keeps them from going to the server, but still makes them participate in the mark/sweep…I wonder why it works for me, though.
there may be a bug there, where mark-missing isn’t working on data with the shape you have
my ui
is a join, as in: {:ui/new-contact [:contact/id :contact/github]}
the bug might be in the mark-missing
since the strip-ui
is working correctly in terms of data sent to the remote
@tony.kay found a minimal case: (fulcro.client.impl.om-plumbing/mark-missing {:a 1} [:a {:ui/anything [:a]}])
outputs: {:a 1, :ui/anything :fulcro.client.impl.om-plumbing/not-found}
I'll just add info on the one you already created
@tony.kay I think I can work on this one
just one thing, how do you work to run the tests on dev? you use lein test
or there is a faster way to feedback loop?
Ah, tests: I would recommend the new fulcro spec browser interface for client and server
run the figwheel build and include -Dtest
to get client tests…you know that one already?
for server tests, start a repl and run (server-test-server)
, then use the URL http://localhost:8888/fulcro-spec-server-tests.html
if you clikc on the menu in UL corner, you can select only :focused
tests…then add that keyword to a spec of interest:
(specification "boo" :focused
...)
cool, setting up everything now 🙂
the old test-refresh still works, but the focused browser interface makes it look like cave-man times
yes, testing cljs in general still a daunting task, most people are still depending on test-refresh, which is too slow...
nice, Fulcro Spec is looking really good! last time I saw it was just a bunch of outlines XD
I think at least some kind of hover to tell you what they mean would be nice. On the wish list 🙂
esp when testing this SQL stuff where I want to turn on/off integration stuff on the fly
yes, it's nice 🙂
had you though about being able to focus tests from the UI?
@roklenarcic turns out this was patched on 3/17/2017 in Om Next. I just did the same patch and was about to submit it…and it conflicted
oh…unless the merge of the PR happened after…in which case the history would show the old patch date even though it isn’t in a newer release
@roklenarcic The issue in Om Next was #853
Of general interest to the channel (and probably beyond). This is Javascript underneath, so there are some fun hacky things you can do to debug/work on errors like this while avoiding checkouts and that whole mess. To work on the patch for the issue I was just looking at, I needed to be able to edit Om Next’s om.next/merge-idents
function.
So, I copied the code for it into one of my own namespaces. From there, you just have to know what the name gets mangled to in js. I just did this:
(defn install-hack []
(js/console.log "Installing hack")
(set! js/om.next.merge_idents merge-idents))
Then I could edit my local version until it worked.of course, I needed to run install-hack
to install it, and watch for hot-code reload overwriting it.
@roklenarcic @tony.kay in this case, would not be easier to just use the om.next from master?
ah, the copy namespace trick, I use that too, was using to debug the previous bug 🙂
I said that because you mentioned this fix was merged in Om, just not released yet
by the way, one PR of mine that got merged will break some of Fulcro tests, hehe, heads up: there is an issue with strip-ui
, because it forces all AST nodes to have children
(adding for those that doesn't have it), the PR that I got merged enables having children
on call
types, and this will make the output from ast->query
to change for those cases
not a major thing, I just got reminded about it
@wilkerlucio children on call types…was that the thing you wanted for your graph queries?
it's kind of a requirement there, in GraphQL when you do a mutation you must declare the returned data from the mutation, otherwise it doesn't run
but I still have to debug something weird that's happening there, because when I try to add children on the mutation this breaks the entire process, still have no idea why, its on my queue to investigate eventually...
for what part?
well, on most cases it should not affect, since nobody seems to be using call with children, what mess cases came to your mind?
what does that expression mean, exactly? Run a mutation that you expect to return something?
yes, think on cases where you are creating or updating some entity, instead of doing a follow up read in a separated requests, you can pull data from it directly from the mutation
this is a common thing in GraphQL world
had you played with the GH GraphQL API? https://developer.github.com/v4/explorer/
I would be more like: [{(create-user {:name "bla"}) [:user/access-token]}]
the read is rooted at the created entity
nop, but it's there available now 🙂
I think it might be some optimisation point for later
right now I just needed that to make my graphql mutations valid
but the current parser, if it isn’t modified to support it, just throws away the return value
but now that you have a query available, it should be a minor fix to get this working without needing to hack into merge, which would be nice
expect somewhere in the Om pipeline, doing a mutation with children just breaks stuff, I want to dig to figure why is that, it's bugging me
what you mean by recursive joined in nature?
that's ok I think, as long as the nodes are available I don't see any restrictions
you make the ident before, using tempid
ah, you mean how to automatically know where to merge the data from the response, right?
Perhaps I’m being too vague. Let me spell out what I’m seeing in my head 😉
1. You send the mutation with query
as it’s rv query. The server can figure out from the parameters and mutation name what entity you’re affecting. As such, it can return data corresponding to your query…As if you’d issued a load with [{ident query}]
…so it can return a map {ident map-value
.
actually, the ident is present (from the server) so Om can even make up the original query once it has the return value
Of course that doesn’t completely eliminate the desire to do some action in response to the return (which still requires augmenting merge), but it does serve a subset of cases that are useful.
yes, this gives you a good extra access point relative to the affected operation, I think it's a nice to have
* confirmed that ui mark missing is fixed in my demo 🙂
lately I've being thinking about a future where we have many graph apis around, and that we can "plug" one into another
@tony.kay if you are down to, this is the demo I've being playing with: http://407d8e53.ngrok.io
(slow, dev build...)
in this one you can see the integration of 2 graphql API's, there is Graph.cool one that handles storage of groups and contacts, and each contact is a github handler
by using the github handler I can hook it up into Github GraphQL
ah, right, it's a github token, you can issue a personal token
you can issue a readonly here ^^^
by having this apis "connected", the Contact
component can look like this:
(om/defui ^:once Contact
static fulcro/InitialAppState
(initial-state [_ _] {})
static om/IQuery
(query [_] [:contact/id :contact/github
{:contact/github-node
[:github/avatar-url :github/name :github/company]}])
static om/Ident
(ident [_ props] [:Contact/by-id (:contact/id props)])
static css/CSS
(local-rules [_] [[:.container {:text-align "center"}]
[:.avatar {:width "100px" :height "100px"}]])
(include-children [_] [])
Object
(render [this]
(let [{:contact/keys [github github-node]} (om/props this)
css (css/get-classnames Contact)]
(dom/div #js {:className (:container css)}
(dom/div nil
(dom/img #js {:className (:avatar css)
:src (:github/avatar-url github-node)}))
(dom/div nil github)
(dom/div nil (not-found (:github/name github-node) ""))))))
I find this really cool, to be able to "jump" from one graphapi to another
actually, 2 of them were on a utility function that was technically wrong…and the new version fixes the function (which breaks the test). Wrong is kind of a strong word, since the function in question was just for logging.
hehehe, devil details
so, it looks like ast->query
now always puts mutations into a map when converting back from an AST…is that right?
that happens if you have children
I think, if the children is nil this should not happen
yeah, I noticed that when using the beta, the strip-ui currently adds children to everybody
no problem 😉
pushed a beta9-SNAPSHOT with your patch @wilkerlucio
thanks, one less lein install
to do when changing computers 🙂
@gardnervickers I’m seeing a PR…confused. I thought we had that fixed