Revamp API to cleanly separate configuration and effects

[neeharv]

This is a more philosophical question about the API of this lib

Currently, the component depends on its effects propagating upwards by a lifecycle-ish onChange method, which usually triggers a change in state of the parent component / update store etc. However, this approach merges together the configuration of the component (scrollDelay, intervalDelay etc), with its effects (onChange), which makes it slightly confusing to grok IMO.

Inspired by React Router v4, I propose the following API

const MyVisibilitySensor = createSensor({
  delayInterval : 200,
  // other opts
});

const App = () => (
  <MyVisibilitySensor>
    {
      ({ isVisible }) => (
        isVisible ? <MainImage /> : <PlaceholderImage />
      )
    }
  </MyVisibilitySensor>
);

This separates concerns very nicely, and also avoids the overhead of having a situation where we have a hierarchy of parent component -> visibility sensor, and the onChange callback triggers a re-render from the parent component downwards. It helps avoid one layer of lifting state up, and is easier to read IMO.

Thoughts?

[Andarist]

How would u use this API with onChange? I specifically mean the combo of onChange + render callback situation

[neeharv]

How would u use this API with onChange? I specifically mean the combo of onChange + render callback situation

Not sure of the question. The render callback is the onChange method now. Every time a visibility change happens, the render callback is executed.

[joshwnj]

@neeharv I really like the direction this is going, thanks for kicking off the discussion :)