3 ms·

I found this as well. As an example (probably just bad coding on my part) I tried to use mobx to track preferences for a photo viewer, every photo then looked a

I found this as well. As an example (probably just bad coding on my part) I tried to use mobx to track preferences for a photo viewer, every photo then looked at the preference state from mobx. App slowed to a crawl because 300 photos are going through a few hundred lines of code each just to see if `showDate` is true/false and because `showDate` is "reactive" there's a whole ton of overhead it tracking that each photo is watching it. Now of course I moved the code that looks at that state up the tree and then pass it down to solve but that kind of defeats the purpose of using it in the first place. The upper components should not have to care directly about data for lower components.

brundolf 6y ago
What I would do in that situation is: 1) If all 300 photos aren't actually visible, make sure React skips actually rendering them (calling their render functions) 2) If they do all need to be visible, and they do all need to update in real time in response to that preference, consider adding a paging mechanism so that not as many are visible at once You have to step back to the root question: do you want all of those components to visibly update immediately in response to that change? If not, make sure they don't try to. If yes, MobX is accomplishing that in the most efficient way possible so you may need to rethink your UI. > I moved the code that looks at that state up the tree and then pass it down to solve This doesn't really make sense to me as a fix, and to be honest I suspect it's merely covering up the problem in a roundabout way.