Fork me on GitHub
#untangled
<
2016-11-24
>
ethangracer03:11:49

@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

wilkerlucio03:11:13

@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

ethangracer03:11:35

that would definitely make sense

ethangracer03:11:03

I remember doing a performance profile in chrome and it took 7 or 8 seconds for the whole re-render cycle to run

ethangracer03:11:16

because of all of the metadata tracking / calls to parseMeta (or something similar)

wilkerlucio03:11:39

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

wilkerlucio03:11:23

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

wilkerlucio03:11:07

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

mitchelkuijpers18:11:25

Is anyone here able to run the untangled-devguide?

mitchelkuijpers18:11:53

A college of mine is trying it out but cannot get it to run

tony.kay18:11:13

I did a recent update…let me look. develop or master?

mitchelkuijpers18:11:08

develop seems the same?

tony.kay18:11:16

hm…yes, seems broken…give me a sec

mitchelkuijpers18:11:57

I am kinda clueless with figwheel 😅 But I do get some nice error messages 😄

tony.kay18:11:36

that’s funky

tony.kay18:11:41

it might be a lein version

tony.kay18:11:56

I’ll send a patch in a second…testing a change

tony.kay18:11:04

pull and it should work

tony.kay18:11:09

I had added modules for playing with i18n

muurtegel18:11:34

Thanks! 🙌

tony.kay18:11:36

and something about the combo isn’t working now. I can swear it was working fine before, but perhaps it is a figwheel incompatibility

tony.kay18:11:23

Just added a mutation return value recipe to the cookbook.

mitchelkuijpers18:11:53

Nice, this was a very usefull addition for us

mitchelkuijpers18:11:59

it is already running in production ^^

tony.kay18:11:23

@mitchelkuijpers the recent patch got you over the workaround, right?

tony.kay18:11:29

e.g. double swap

mitchelkuijpers18:11:31

We needed it to put a resolved id in localstorage after a mutate

mitchelkuijpers18:11:35

Yes this fixed it

tony.kay18:11:06

ah, yeah, I could see that

mitchelkuijpers18:11:24

That was the only case why we needed it never used it before

tony.kay18:11:47

glad you pointed out a good use-case. I hadn’t really thought of a good one yet

mitchelkuijpers18:11:34

We have a recently-used list in localstorage and we put the resolved id after a create of something in localstorage