This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # arachne (3)
- # beginners (41)
- # boot (300)
- # cider (17)
- # cljs-dev (37)
- # cljsjs (4)
- # cljsrn (5)
- # clojure (249)
- # clojure-boston (3)
- # clojure-czech (4)
- # clojure-dev (14)
- # clojure-greece (183)
- # clojure-nl (2)
- # clojure-russia (11)
- # clojure-spec (135)
- # clojure-uk (37)
- # clojurescript (56)
- # community-development (8)
- # cursive (22)
- # data-science (4)
- # datomic (150)
- # devcards (6)
- # emacs (5)
- # euroclojure (8)
- # funcool (18)
- # hoplon (29)
- # immutant (1)
- # jobs (1)
- # lambdaisland (3)
- # lein-figwheel (7)
- # leiningen (18)
- # mount (1)
- # om (81)
- # onyx (95)
- # planck (50)
- # proton (6)
- # re-frame (62)
- # reagent (2)
- # ring (1)
- # robots (1)
- # spacemacs (2)
- # specter (88)
- # test-check (32)
- # untangled (23)
- # yada (1)
Hello, i have one question about the callback on the remote part of the reconciler
what function is merging the state? i have 2 candidates,
merge-sends #(merge-with into %1 %2)
to be more specific, my remote returns an empty key like
but after passing it throught the callback to merge it, the key dissapears
my app crashes on
add-root! when I uncomment the lines in my queries with recursive joins
I ran into issues with my recursive queries + unions because of a combination of this issue: https://github.com/omcljs/om/issues/604 and when components get re-rendered due to a
transact! it was receiving the result of the root query and not the query rooted at the union. It didn’t cause any crashes, just weird rendering behavior.
@anmonteiro: will do, wanted to see if anyone else had run into it, if I was missing something already known
Does it work for initial render and then break when something transacts or merges in a server response?
@ethangracer: sounds like a bug, I’ll be able to tell more with a minimal repro, thanks
I actually haven’t really felt the need to use it, so if it solves your problem and doesn’t break the tests, should be good 🙂
I know I've seen a similar stack trace when building indexes related to recursive queries though. I think I had two recursive joins in one query (for a graph).
I have been steering away from using process-roots too, but now my root query is getting pretty busy. How are you reconciling remote reads when nested components need new info (say from a lazy loaded list of options)?
@cmcfarlen: not sure I understand the question, but the AST is just much more powerful than what it might look like at the beginning 🙂
:value returned by a mutate function is ignored, right? Why is it even there/documented?
@anmonteiro: I'm certain I didn't explain it well. I'm also certain I need to go back through my parser code with a fresh perspective. I wrote it initially months ago and tried to make a general reader that accepts hints from the query parameters (to say, delay a remote read or elide a level of state for :query-root). Its pretty nice for some situations, but more and more I am finding myself trying to sidestep that stuff which tells me its getting crusty.
I guess I don't have a good sense of what an Om Next app is supposed to look like at scale
Like, should I be manually resolving links in my
read for every key that can have idents it its value(s)?
Oh, hmm. I've been avoiding Om's built in normalization; I thought it was only designed for getting started.
server side it can be a bit more work of course depending on what db you’re using - but it’s not going to be any worse than GraphQL or Relay
@dnolen: So the idea is that it's correct to do something like the
(into  (map #(get-in st %)) (get st key)) in
get-people because normalization ensures that the map you get will only have keys that were in
Person's query? https://github.com/omcljs/om/wiki/Components,-Identity-&-Normalization#appendix
I see a lot of example code do things like
(into  (map #(get-in st %)) (get st key)) in their
reads to dereference links. Is that recommended, or is that just a shortcut for small tutorials?
@anmonteiro: repro for the issue I discussed earlier here: https://github.com/egracer/union-recursion-bug
Line 15 in
app.ui is commented out to avoid the crash on initial render. uncommenting causes the crash. switching to om-35 with the same line uncommented does not crash.
@dnolen: Thanks for being patient with me! I get it now. 🙂 Works like a charm (of course).
Is there a preferred way to map queries to several REST endpoints? The two strategies that come to mind are either a separate remote for each endpoint (which sounds like it could become a lot of remotes) or a single remote that picks things apart in the
send (which sounds difficult). Is one considered better than the other?
also @anmonteiro I can file an issue if that helps, looks like it only happens for recursion nested in a union
@anmonteiro: k, wanted to do the best to reproduce the issue as I encountered it but will strip out untangled and let you know when it’s done — doesn’t currently use the server but i’ll get rid of those pieces too
@ethangracer: nothing against untangled. I’d just prefer to look at something bare
@anmonteiro: ok removed all the non-essential stuff. I can’t get it to reproduce with less, 5 simple components and om setup, all in
app.core. hope that makes it easier. the commented recursive query is the culprit: https://github.com/egracer/union-recursion-bug/blob/master/src/app/core.cljs#L14