Re-add isMobXReactObserver property on class components
#839
Comments
|
yikes, removing a bunch of observers might help finding the offending
component
…On Fri, Feb 14, 2020 at 6:50 PM Yousuf Nejati ***@***.***> wrote:
Hey guys,
I'm running into a stack overflow and not sure what to make of it. Making
an issue here in case it happens to evolve into something.
Ends up in the endless reactive render cycle. Maybe allowStateChanges is
the culprit here, or more like I'm doing something wrong. For limited
context, I have a page with a container (which is an observer) with easily
hundreds of child containers (which are also observers) and where each
child container has multiple labels (also observers). The browser logs
state that the overflow is coming from Label.render(), but might be
deceptive. Started noticing it after upgrading to v6, but can't say if it's
the actually cause.
Going to try downgrading to 5 in attempts to isolate, and will update
here. And/or trying to reproduce this with minimal noise that shareable.
Happy to provide more context within limits, just let me know.
(anonymous) (mobx-react.umd-6.1.4.js:formatted:189)
trackDerivedFunction (mobx.umd-5.14.2.js:766)
Reaction.track (mobx.umd-5.14.2.js:1794)
u (mobx-react.umd-6.1.4.js:formatted:187)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:201)
r.render (mobx-react.umd-6.1.4.js:formatted:203)
allowStateChanges (mobx.umd-5.14.2.js:976)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:189)
trackDerivedFunction (mobx.umd-5.14.2.js:766)
Reaction.track (mobx.umd-5.14.2.js:1794)
u (mobx-react.umd-6.1.4.js:formatted:187)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:201)
r.render (mobx-react.umd-6.1.4.js:formatted:203)
allowStateChanges (mobx.umd-5.14.2.js:976)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:189)
trackDerivedFunction (mobx.umd-5.14.2.js:766)
Reaction.track (mobx.umd-5.14.2.js:1794)
u (mobx-react.umd-6.1.4.js:formatted:187)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:201)
r.render (mobx-react.umd-6.1.4.js:formatted:203)
allowStateChanges (mobx.umd-5.14.2.js:976)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:189)
trackDerivedFunction (mobx.umd-5.14.2.js:766)
Reaction.track (mobx.umd-5.14.2.js:1794)
u (mobx-react.umd-6.1.4.js:formatted:187)
(anonymous) (mobx-react.umd-6.1.4.js:formatted:201)
r.render (mobx-react.umd-6.1.4.js:formatted:203)
finishClassComponent (react-dom.development-16.11.0.js:18597)
updateClassComponent (react-dom.development-16.11.0.js:18550)
beginWork$1 (react-dom.development-16.11.0.js:20307)
beginWork$$1 (react-dom.development-16.11.0.js:25860)
performUnitOfWork (react-dom.development-16.11.0.js:24808)
workLoopSync (react-dom.development-16.11.0.js:24784)
performSyncWorkOnRoot (react-dom.development-16.11.0.js:24383)
(anonymous) (react-dom.development-16.11.0.js:12326)
unstable_runWithPriority (react.development-16.11.0.js:3096)
runWithPriority$2 (react-dom.development-16.11.0.js:12276)
flushSyncCallbackQueueImpl (react-dom.development-16.11.0.js:12321)
flushSyncCallbackQueue (react-dom.development-16.11.0.js:12309)
batchedUpdates$1 (react-dom.development-16.11.0.js:24505)
reactionScheduler (mobx.umd-5.14.2.js:1904)
runReactions (mobx.umd-5.14.2.js:1880)
endBatch (mobx.umd-5.14.2.js:1580)
_endAction (mobx.umd-5.14.2.js:965)
executeAction (mobx.umd-5.14.2.js:919)
res (mobx.umd-5.14.2.js:904)
(anonymous) (PageStore.ts:179)
finished (PageStore.ts:179)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#839?email_source=notifications&email_token=AAN4NBDYLU4MVPXKATJOJXLRC3RZDA5CNFSM4KVNWSBKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INUZTPA>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN4NBB4OOU6FMEKCQT7YCTRC3RZDANCNFSM4KVNWSBA>
.
|
|
Okay, thanks. I'll keep trying to isolate and see what I can come up with. Hopefully it is just that I'm doing something wrong, and not an issue of the lib. |
|
Not a MobX problem, or an actual cycle. Simply creating too many initialization invocations on startup as is necessary of an extremely complex application. Exploring and applying asynchronous solutions and simplification will solve this problem. Closing this issue. |
|
Reopening issue. It was caused by wrapping observer within observer, and explains the reason for a large nested stack of reactive render initializations, i.e. Component.render -> reactiveRender -> Reaction.track -> trackDerivedFunction -> anonymous in reaction.track -> allowStateChanges, etc. Even when all observables were stripped from component renders, and were only being rendered once on mount. Up until v6, observer component classes were modified with the property In this particular case, checking on this property to ensure that whatever component class that is provided to an HOC is an observer can cause problems, since it will return false, requiring that the component class is wrapped in A quick search, and |
ynejati
changed the title
ynejati
changed the title
isMobXReactObserver property on class components
…ck on class components.
It probably was an accident. I would like to see a consolidated behavior for functional components too. Perhaps it might be better to start at |
…ck on class components.
…ck on class components.
…class components (#843) * Update size limit config to 4.1 * Issue #839: Re-add isMobXReactObserver property and perform check on class components. * Better observer class warnings, WIP * Add __DEV__ as global in lint config * Better logging, fix tests, and clean up * Log redeclared observer warning in both production and development * Fix broken tests - Update mobx-react-lite dependency version - Import observer batching in jest setup config * Semantic versioning greater or equal to mobx-react-lite dependency version 2.0.6
Hey guys,
I'm running into a stack overflow and not sure what to make of it. Making an issue here in case it happens to evolve into something.
Ends up in the endless reactive render cycle. Maybe allowStateChanges is the culprit here, or more like I'm doing something wrong? Maybe both?
For limited context, I have a page with a container (which is an observer) with easily hundreds of child containers (which are also observers) and where each child container has multiple labels (also observers).
The browser logs state that the overflow is coming from
Label.render(), but might be deceptive. Started noticing it after upgrading to v6, but can't say if it's the actually cause.Going to try downgrading to 5 in attempts to isolate, and will update here. And/or trying to reproduce this with minimal noise that shareable.
Happy to provide more context within limits, just let me know.
The text was updated successfully, but these errors were encountered: