This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-24
Channels
- # arachne (1)
- # bangalore-clj (11)
- # beginners (177)
- # boot (63)
- # business (1)
- # cljsjs (21)
- # cljsrn (3)
- # clojars (4)
- # clojure (116)
- # clojure-art (4)
- # clojure-belgium (3)
- # clojure-india (1)
- # clojure-italy (6)
- # clojure-russia (14)
- # clojure-spec (8)
- # clojure-uk (67)
- # clojurescript (51)
- # community-development (5)
- # cursive (13)
- # datascript (14)
- # datomic (29)
- # devcards (3)
- # emacs (3)
- # events (3)
- # funcool (4)
- # hoplon (29)
- # mount (6)
- # om (34)
- # om-next (5)
- # onyx (16)
- # perun (8)
- # planck (22)
- # re-frame (13)
- # reagent (5)
- # ring-swagger (21)
- # rum (3)
- # spacemacs (3)
- # specter (1)
- # untangled (39)
@wilkerlucio: yes we've seen that behavior before, we ended up manually writing components that composed queries as many levels deep as we needed to simulate recursion. That solved our performance issue. We were never able to identify the source of the bug though
@ethangracer thanks for letting me know that I'm not the only one affected, I was talking to Antonio, we are thinking it might be related to path optimization, given that each recursive component affected will trigger an individual re-read of the app state, and it has to build each one from the root... it makes sense, and also the number of slow queries on my console matches with the number of recursive components being re-render, still need to confirm but seems to be the problem root
that would definitely make sense
I remember doing a performance profile in chrome and it took 7 or 8 seconds for the whole re-render cycle to run
because of all of the metadata tracking / calls to parseMeta (or something similar)
yeah, I have a gut feeling that there is a way to optimize the recursive reading, since in a case like this all of the chain is always going to be re-read, it seems wasteful to compute one by one, maybe there is a way to make that more efficient
my case is not so dramatic, it still takes less than a second, but this is happening on each user input change, making it noticeable
I'm thinking that my easy way out would just be to isolate the input to avoid the recursion render at this point, but a general solution would be nice
Is anyone here able to run the untangled-devguide?
A college of mine is trying it out but cannot get it to run
master
develop seems the same?
I am kinda clueless with figwheel 😅 But I do get some nice error messages 😄
You rock man
and something about the combo isn’t working now. I can swear it was working fine before, but perhaps it is a figwheel incompatibility
https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/mutation-return-value
Nice, this was a very usefull addition for us
it is already running in production ^^
@mitchelkuijpers the recent patch got you over the workaround, right?
We needed it to put a resolved id in localstorage after a mutate
Yes this fixed it
That was the only case why we needed it never used it before
We have a recently-used list in localstorage and we put the resolved id after a create of something in localstorage