This issue tracks tasks related to the React DOM implementation of the experimental React Events API (
Note: For now this is completely experimental and won't affect the open source builds of React.
A use case to consider: being able to programmatically move focus to an element without
Consider whether we need this at all. Some browsers have a native hitslop and we could work with vendors on any potential improvements to the native system
Dev Tools (#15267)
The text was updated successfully, but these errors were encountered:
In example showing a "sticker" with a date at the top of the message feed. When a scroll is induced programmatically (or by the browser) then it's distracting to show such thing, but when a user scrolls on their own it makes sense from the UX perspective.
Well, it's not a clear way of determining that in onScroll, so some kind of other tracking flags have to be introduced to solve this. It's in general tricky to handle all possible reasons of why scroll has been triggered:
And those are just things that user can do. Other than that UI might get mutated (even by React, so we can't really track it in userland) and thus trigger scroll event, and as @gaearon mentioned setting scrollTop also triggers scroll event.
And even if u manage to track all reasons of user-induced scrolling it's unobvious when to clear you your flag(s) because you have to consider inertia scrolling etc
The solution would be to figure out best heuristics of detecting this. Can't give much detail right now, because this truly is an overcomplicated problem for such a "simple" thing. Web
Consider another one - a floating "scroll to bottom" button which covers part of the chat feed. We'd like to show such when a user is scrolling on their own (with a delay etc) and hide it after they stop scrolling so we don't cover part of the chat feed constantly. And we i.e. have to work around for situations like mobile keyboard triggering onScroll (cause of the resize etc).
Given the grand retooling happening to the event system here, I would like to re-raise the following request under this umbrella, from #3751 (comment):
TL;DR: listen to
We're not longer working on this particular approach and will be exploring other ways to work with the DOM event system in the future. We've concluded that the "Flare" event system is too high-level an abstraction and we'd like to explore something that is a bit more familiar to developers familiar with the DOM (e.g., addEventListener) and React's existing tools (e.g., hooks). Our goal is still to make it possible for library authors to work with passive events, capture/bubble phase, custom events, and events occurring on the document from within a React function component...while reducing the amount of event-related code needed in ReactDOM. Ultimately building both intermediate abstractions like the Responder Event system and high-level abstractions like