Issue #839: Re-add isMobXReactObserver property and perform check on class components#843
Conversation
|
Updated the change log. Going to need to actually increment the version, potentially add tests, and update the Readme. Looking for guidance on what you'd like me to do. Should have marked it as a draft PR, but can't backtrack, so going to mark as WIP for now. |
|
Do not need to bump version, will happen in a release process. I would probably wrap both of those code blocks to Adding test good idea for sure and to tweak the on that is broken as well. Also thinking it might better to use Symbol instead of string property. |
|
Good point. Also, something just realized, if the render of a parent class
is a reaction as a result of observer and that subclass overrides the
render of the parent, the render is no longer reactive.
…On Fri, Feb 28, 2020, 6:00 AM Daniel K. ***@***.***> wrote:
Do not need to bump version, will happen in a release process.
I would probably wrap both of those code blocks to __DEV__ check as we
don't this in production.
Adding test good idea for sure and to tweak the on that is broken as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#843?email_source=notifications&email_token=ADAQOYZPA3WES2LU2B6ULDDRFEKHFA5CNFSM4K5QCYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENITNMI#issuecomment-592524977>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADAQOYY5TERFRZCDAATKPFTRFEKHFANCNFSM4K5QCYAA>
.
|
|
Okay, I see now. Regarding a subclass who extends a parent class and overrides the parents reactive render. This behavior is not supported. The subclass will need to re-declare itself as an observer. That is fair. Curious, what happens to the reaction of the parent class. Is it leaked? |
danielkcz
left a comment
There was a problem hiding this comment.
Looks better, although I am still not happy that functional components won't have this check. I would like to see it unified.
|
Decided to keep it simple, and just log a warning instead of performing some hand holding. I haven't heard anyone else complain about the removal of the |
|
@ynejati Are you willing to continue on this PR? |
|
@FredyC, yep. Sorry, been MIA. These last couple of months have been weird. |
51c87dd to
ab88a4e
Compare
|
Please update the size limit config to |
|
Bummer. Okay. |
|
I'll fix the tests, but just so you know they are also broken on the master. |
…ck on class components.
|
Oh! That's interesting. For a while, I thought it's some failure on Coveralls side. Only now when I saw failed test-size I checked the other one too. If you have time for it I would certainly appreciate if you can fix those. I believe it's merely about import the observer batching, probably best to do that in jest.setup.ts. |
- Update mobx-react-lite dependency version - Import observer batching in jest setup config
ab88a4e to
3f6a121
Compare
|
@FredyC, this thing is ready when you get a chance. Thanks, man. |
danielkcz
left a comment
There was a problem hiding this comment.
Thanks, just one last change, please.
|
Thanks a lot, that was somewhat painful PR given how little it is :) |
| const target = componentClass.prototype | ||
|
|
||
| if (componentClass[mobxObserverProperty]) { | ||
| const displayName = getDisplayName(this) |
There was a problem hiding this comment.
This can't be correct, as this isn't bound at this (lol) point, I think componentClass.displayName || componentClass.name will do the trick here
There was a problem hiding this comment.
In Javascript "strict" mode this will die hard iirc
There was a problem hiding this comment.
Well, that's silly. Surprised that it's taken this long to catch it. How embarrassing. I guess the test failed to catch it as well. I will submit a PR later today if someone doesn't get to it before me.
There was a problem hiding this comment.
target seems to work too


Fixes #839
READMEif applicable