-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support React 18 #3005
[WIP] Support React 18 #3005
Conversation
|
Highlight impact of startTransaction updates vs local state: https://codesandbox.io/s/usedeferredvalue-issue-iteration-forked-ovvsl / https://codesandbox.io/s/usedeferredvalue-issue-iteration-forked-li6uj?file=/src/index.js |
tearing scenarios Is this problem difficult to solve in mobx ? |
My current understanding (and could be wrong) is that if you want to avoid tearing, the component can not depend on mutable state. I don't think that's reasonably doable with mobx. |
testing-library/react-testing-library#509 has been closed with their new alpha now 🥳 |
React 18 is now in beta |
The author has actually made it clearer .mobx works fine with React 18. And I don’t think we need to be impatient, I dont think online project will use React concurrent mode quickly, i think there will be a lot of works to do. even if project upgrade React to ^18.0.0. i think we still use Legacy Mode or Block Mode. and i made some test. yes, there are some tearing problem in cooperating with mobx and react 18 concurrent mode. but the final render result is ok. |
|
re; > test against https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering I implemented it here; https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering/pull/63/files against the current released version of mobX. |
@mweststrate what's the status of this? Can we expect a release soon? If there are any "good first issues" to tackle that would help prep this, can you share a list? |
Sorry haven't really been following along React 18 anymore in the past year, so lost most of the context I had on it😅. The primarily thing that needs to happen is to bump the peer deps and unit tests to use React 18, so PR for that is welcome! |
Is this really true? We had to switch back to ReactDOM.render() today after hitting cases where mobx observer components wouldn't rerender randomly even though their underlying observables were changing. Mind you we're on Mobx 5.15.7 + mobx-react-lite 2.2.2. However this thread doesn't lead me to believe that going through the gargantuan task of updating to latest and greatest mobx will somehow resolve the issue: #2526 Would appreciate guidance here as we are hugely dependent on mobx (250 occurrences of useLocalStore in the codebase) and switching to useState as is suggested in the above thread sounds worse than a root canal (or 4). |
We didn't have breakages reported / found, when testing with the alpha. If
something breaks for you, please reproduce, isolute and report it so we can
look at it. But at this moment we didn't release anything officially
supporting React 18 yet, since no one was able to yet carve out the time to
update everything, so personally I can't recommend jumping directly on
React 18 yet.
…On Tue, Apr 5, 2022 at 3:48 AM Noah Shipley ***@***.***> wrote:
Is this really true? We had to switch back to ReactDOM.render() today
after hitting cases where mobx observer components wouldn't rerender
randomly even though their underlying observables were changing. Mind you
we're on Mobx 5.15.7 + mobx-react-lite 2.2.2. However this thread doesn't
lead me to believe that going through the gargantuan task of updating to
latest and greatest mobx will somehow resolve the issue: #2526
<#2526>
Would appreciate guidance here as we are hugely dependent on mobx (250
occurrences of useLocalStore in the codebase) and switching to useState as
is suggested in the above thread sounds worse than a root canal (or 4).
—
Reply to this email directly, view it on GitHub
<#3005 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN4NBDSYB3AVI7QMXENX43VDOSXFANCNFSM47HUFYKA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@mweststrate do you or you know any community contributors who do freelancing / consulting? My company would love to do a contract with them to flesh out support! I think there's probably some challenges around all the |
@airhorns We're in the same boat. We could pool resources if someone qualified is available to truly take this on. @mweststrate The breakages are psuedorandom. Usually related to a query returning during a render in our complex MDI which then changes a prop wrapped by useAsObservableSource in a parent store which then the child component isn't realizing it has changed and thus is rendering stale data. Not sure how I would go about producing a minimum example as things 98% worked but then mysteriously would break after a seemingly unrelated change elsewhere that I believe subtly changed timings or render paths. |
@noah79 I follow a simple rule - do not mix mutable Mobx with immutable React state / props. I use Mobx for everything, even for local state, this is how I avoid UPD: For anyone interested, I've created a demo with Mobx + React 18 and so far it just works with no issues: https://codesandbox.io/s/vigilant-hellman-3mjsty?file=/index.js |
@kubk I'm aware it's deprecated. We're still happily on Mobx 5.15.7 and have seen no reason to upgrade and lose decorators, be forced to use makeAutoObservable, etc. I considered upgrading this week due to React 18 breakages, but nothing I've read here leads me to believe it's going to actually work for all of our complex cases. Your codepen is super simplistic compared to our running app (A customizable MDI that sells for 7 figures and is used by companies like Swarovski, ASICS, Restoration Hardware, Under Armor and others). If I knew that it was bulletproof against concurrency mode then I might take the plunge and rewrite the literally hundreds of stores that use mobx, but until I see true concurrency support, it's a ton of work for likely zero tangible benefit. Hell the benchmarks say Mobx 6 is slower than what we're on! Decorators are even moving forward in javascript so I have a feeling someday a mobx 7 will come out that will embrace decorators again and the API will (hopefully!) return to the much kinder one that preddated version 6. I like my decorators. I dislike needing to call magic methods in my constructors, parent classes, etc. I like knowing if a class instance variable is actually observable or not (decorated or not), etc. It ain't deprecated in v5.15.7 :) |
Decorators are supported in 6 as well
Tried the codemod?
You know that that isn't the meaning of the word deprecated ;)
|
@mweststrate Hi, there is a new Create-React-App release that ships with React 18, so it's probably the time to allow installing Mobx alongside React 18. I'd like to simply bump allowed react versions in mobx-react-lite and mobx-react. Should I create a separate PR or continue working here? |
Hey! I started working on a local branch, updating tests etc, but forgot to
push and I'm travelling coming week, will try to continue after that again!
…On Wed, 13 Apr 2022, 20:54 Egor G, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In packages/mobx-react-lite/package.json
<#3005 (comment)>:
> @@ -39,7 +39,7 @@
"dependencies": {},
"peerDependencies": {
"mobx": "^6.1.0",
- "react": "^16.8.0 || ^17"
Isn't it a BC break? Can I change it to ^16.8.0 || ^17 || ^18?
—
Reply to this email directly, view it on GitHub
<#3005 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN4NBG6D5F6XCTGZI5MVZ3VE4RA3ANCNFSM47HUFYKA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Being superseded by #3387 |
Should be fixed in [email protected] / [email protected] |
First attempt at full React 18 support.
Didn't get very far since react-testing-library isn't updated yet :)
differentiate low and high prio updates. always use startTransition by default / optionally, hook for the exceptions?startTransition
looks to work as expected, see above