-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Compat: Add basic shims for some scheduler functions #2912
Conversation
📊 Tachometer Benchmark ResultsSummaryduration
usedJSHeapSize
Results02_replace1kduration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
03_update10th1k_x16duration
usedJSHeapSize
07_create10kduration
usedJSHeapSize
filter_listduration
usedJSHeapSize
hydrate1kduration
usedJSHeapSize
many_updatesduration
usedJSHeapSize
text_updateduration
usedJSHeapSize
|
Size Change: +371 B (0%) Total Size: 42.3 kB
ℹ️ View Unchanged
|
Great! There's also at least one export on |
🙈 |
I don't know why preact must insist on running. |
@yisar I'm not sure if you're aware, but our implementation of
Going into other frameworks issue trackers and posting something akin to "your framework sucks" is just rude. You might want to take a look at our Code of Conduct page again. |
@marvinhagemeister Once you introduce the shim, a lot of disagreements will arise because the shim is inaccurate. In essence, this API is not just to execute a callback. The reason why Of course, this is not important. What I need to explain is that once the shim is introduced, there will be more differences. The introduction of shim is not a good behavior, it is full of uncertainty and instability. It's also worth mentioning that I don't think preact is terrible, I just think it's unwise to introduce an unnecessary shim. You can give up |
@yisar preact does not need to have accurate scheduler implementation, as you noted as well, so why not have the APIs from scheduler exported for the libraries that make use of them? Regardless of their accuracy, as long as they do not break the functionality, there's no harm in having them. Marvin already added a block of comment where all of the concerns that one might have, are addressed. So, any discussion regarding the accuracy, or validity of them should start from there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @marvinhagemeister! This will make the adoption of libraries much easier 🎉
You're right. If it's just for sharing the third-party library, it can be done without causing damage. But what if users need to implement their own libraries with the APIs of the I notice that this PR has been merged, and I don't want to argue about this. |
Was notified of a library that makes use of some experimental concurrent mode APIs from React. This PR adds the necessary shims for that.
See https://github.com/dai-shi/use-context-selector/pull/36/files
cc @mischnic