Scrolling inside different containers

[ganderzz]

Right now React-Scroll-To only supports scrolling on the window, but there are use-cases where a user might want to scroll inside different containers (say a div).

Proposed Idea:
Add a new prop to <ScrollTo> to accept a 'scrolling location'. This would look like:

<ScrollTo container={divRef}>
    {scroll => ... }
</ScrollTo>

Where the container could be a Ref passed in. If nothing is given in the container prop, default to using window.

[jikkujose]

Not really sure this is possible, but an API I would love to have is something like this:

<ScrollArea width={x} height={y} render={
  (left, top) => <Stuff />
} />

• So that Stuff could be a big inner component which will get masked to a the dimensions provided by the ScrollArea
• Ignoring any one of the dimension expands the ScrollArea to the width of its children

[ganderzz]

I like where this is going, it'd be great for the component to inherently know its scroll area without defining it. But, a few issues come up:

• How would I then scroll using window? We could wrap the whole app in a ScrollArea and pass down the action, but seems messy for this use-case
• Since the child is a function, it has to be evaluated before the DOM object can be accessed, or a proper height can be calculated.
• ScrollArea would have to wrap the children in a div to account for an array of children. Not a problem, but changes behavior of the existing component.

[jikkujose]

Wrapping the whole site too with the component, though might look messy seems to be an elegant way to use the same API for all use cases. We can forget about the lower level abstraction that touches window & only bother about ScrollArea and its rather small API surface.

[newyork-anthonyng]

@ganderzz I threw together this Proof of Concept in CodeSandbox.

The API looks something like, which uses context:

import { ScrollTo, ScrollToContainer } from "react-scroll-to";

const App = () => {
  return (
    <ScrollTo>
      {scroll => (
        <div>
          <button onClick={() => scroll(0, 100)}>Scroll down</button>
          <ScrollToContainer style={containerStyle}>
            <LongBaconIpsumText />
          </ScrollToContainer>
          <ScrollToContainer style={containerStyle}>
            <LongBaconIpsumText />
          </ScrollToContainer>
        </div>
      )}
    </ScrollTo>
  );
};

I tried an example without context and only used containerRef. The issue is that <ScrollTo /> would not rerender when the containerRef was finally available, and containerRef would always be null.

Let me know what you think of this.

[ganderzz]

@newyork-anthonyng I'm really liking it! A few things to think about:

• What about calling the "ScrollToContainer" component ScrollArea. I like keeping the terminology centered around ScrollTo, but playing around with the example I had a brain fart and thought, "I wonder what container this component scrolls to?"

• Had to add a removeScrollToContainers function. If we wrap a ScrollToContainer in a toggle, the component will keep adding itself on every mount. Made a example here. (Removing ComponentWillMount in the ScrollToContainer will console.log the growing list)

[newyork-anthonyng]

@ganderzz Good point 👍

I created a new Pull Request to increase the code coverage to 100%. Once that's merged, I can try putting a Pull Request in for this issue.

[ganderzz]

... On adding the ScrollArea to ScrollToHOC:

I could maybe see this going two ways:

• What if internally ScrollToHOC uses the render prop ScrollTo. This would allow any low-level functionality be located in ScrollTo, and have ScrollToHOC automatically consume any new features
• Creating a new component/class that handles the scrolling/active scroll areas in an abstract way that both the ScrollToHOC and ScrollTo consume. Will need to do some testing, but this may be ideal as the dependency structure would be more tree-like, instead of the bulk of the functionality being silo'd in ScrollTo

[newyork-anthonyng]

@ganderzz

To me, it seems like the first option uses composition, and the second option uses inheritance. I remember reading this article from the React docs. It seems to be leaning more in favor of using composition. Thoughts?

[ganderzz]

@newyork-anthonyng My wording was off, I was thinking of it more like reusable functions instead of an actual class hierarchy. But thinking about it more, it would require a single global instance of a ScrollArea array.

I'm in favor of option 1 due to a single global object sounding like a bad idea. Option 1 would better encapsulate the ScrollArea array into each instance of ScrollTo and ScrollToHOC. Playing around with the idea, here's an example of option 1.