Is anyone using `BringIntoViewRequester` directly?...
# compose
z
Is anyone using
BringIntoViewRequester
directly? How/what for? I’m thinking of converting it to an interface that
Modifier.Node
subclasses need to implement, would this be good/bad for you? Please respond in the thread.
c
I am using this but I’ll need to double check what for in the morning
a
We are using it to scroll to some element in a column on button click. Does it mean it'll be harder to call
bringIntoView()
outside of a modifier node?
z
Yes.
I looked at GitHub and there are lots of uses of the modifier factory that would not be trivial to port, so I think it’s gotta stay
v
I have a lot of usage 😅
j
Yes! I use it for my WYSIWYG editor which is a LazyColumn with different composables inside (for text, images, tables et cetera). I use the requester to scroll along the user's place of editing/typing. I don't know how I should use it when it's converted to an interface?
v
There are 4 use cases, 1) is separate and could quite easily be just a node, but 2), 3), 4) would probably lose ergonomics: 1) Instantiating an object for a custom
Modifier.scrollOnFocus
modifier. The instance is shared like this:
Copy code
.bringIntoViewRequester(requester)
    .then(ScrollOnFocusElement(padding, center, predicate, description, requester))
In this case if the `ScrollOnFocusElement`/`ScrollOnFocusNode` would be able to implement
BringIntoViewRequesterNode
(it's currently internal) we wouldn't need to instantiate upper in the hierarchy. 2) Bringing a playing track into view on shuffle play:
Copy code
LaunchedEffect(isPlaying) {
        if (isPlaying) {
            scope.launch {
                // Bring track into view with 32 units vertical padding
                bringIntoViewRequester.bringIntoView(...
3) Ensuring a question is in viewport when toggling software keyboard
Copy code
LaunchedEffect(isKeyboardVisible) {
        bringIntoViewRequester.bringIntoView(
4) Initial scroll to a specific point in a large scrolling page
Copy code
LaunchedEffect(Unit) {
    if (initialScrollToRecommendations) {
        scope.launch {
            bringIntoViewRequester.bringIntoView(...
👍🏻 1
c
I have a BringIntoViewRequester on a text field inside a modal bottom sheet (m2). At the time I wrote this it solved a problem for me, but I’m not sure it’s still needed.
g
I would use it if I could customize the target location of the view that needs to be brought in. Like maybe I want it at the top/middle/bottom of a lazy column. Or I want to leave some space/margin at the bottom so another composable (like a textfield error/warning) is visible when the first one is brought into view. Though I could control this last one one with the Rect parameter. OR maybe I’m just misunderstanding the API
z
@Jacob Ras that should work automatically in BasicTextField2
@gsala that’s a separate issue. I think we have a feature request tracking it but not at my computer atm. And the Rect parameter is to specify which part of the child to bring into code, not which part of the viewport to consider “visible”
👍 1
🙏 1
Ok we’ll leave the modifier factory in, clearly has a lot of utility. Thanks for responding yall!
🙏🏼 1
v
Thanks for doing an advice round before changing!
z
Related question: Is anyone implementing
BringIntoViewResponder
themselves?
v
I do, but currently only for debug/logging purposes. I was planning to implement something that would always center the requesting content in the parent, but never got around doing that properly.
👍🏻 1
320 Views