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
are recursive queries broken for anyone on alpha36?
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.
@ethangracer: repro appreciated 🙂
@noonian: yeah I’ve had that too, everything in my db is normalized though
@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?
no, the crash happens before the initial render… let me get the stack trace
@ethangracer: sounds like a bug, I’ll be able to tell more with a minimal repro, thanks
@anmonteiro: it looks like @ethangracer ran into the same bug I did here: https://github.com/omcljs/om/pull/691
@cmcfarlen: definitely not the same bug
sorry for the delay, the patch looks good
but I haven’t used
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?
@peeja: I’d go for multiple remotes
it would just look better overall
you could do nice dispatching on them
e.g. multimethods, core.match
also @anmonteiro I can file an issue if that helps, looks like it only happens for recursion nested in a union
@ethangracer: sorry I’m not going to look at that
please make a minimal repro. Including untangled is most definitely not minimal
also should be runnable without a server
@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
takes me less time, as you could imagine
yup, no worries
@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
@ethangracer: looks great, thanks
I’ll take a look at it tomorrow
sounds good, thanks!