[Doc, enhancement] Consider 2.0 migration guide?

[estaub]

I spent an hour or two trying to upgrade to 2.0 yesterday and gave up - it's just not worth anything to me beyond being able to stay current. I'll probably try again in a few months - but if it's a hassle I'll start looking at other options.

IMHO, 2.x does little new that will motivate most current users to upgrade, if they're getting what they need now. I'm not saying it wasn't a good idea, just pointing out that the effort required for upgrading needs to be minimized to pull folks forward who are just motivated by trying to keep up-to-date. In the context of the tiny API footprint, 2.x is is a tough upgrade, but mostly for reasons that might be fairly easily mitigated by a little doc.

1.) Dumb, I know, but yesterday I couldn't think how to look back to the 1.x docs without cloning from it. Consider a link to https://github.com/souporserious/react-measure/tree/1.4.7 for comparison.

2.) Summarize the API changes, probably including a before-after table for each 1.x prop. A simple example: 1.x had onMeasure; what prop or design-pattern should I use in 2.x in it's place? onResize?

3.) Show before/after for common usage patterns?

[souporserious]

This is a great idea! Thank you for sharing your thoughts. Sorry, I've super busy trying to manage some of my other libraries 😓 but I'll get to this as soon as I can. I'll work on a migration path to hopefully ease that pain. Would love to see how you've used it in 1.0 just to make sure I can account for the use case.

Again sorry about this, I didn't realize how much removing findDOMNode would hurt everyone 😩

[estaub]

For me, at least, removing findDOMNode wasn't an issue - it's the whole API rework. My use is about as simple as can be, and I'm sure that the v.2 implementation is simple too - I just didn't hit it immediately.

Simplified:

                <Measure whitelist={['width']}
                         onMeasure={dimensions => this.setState({ width: dimensions.width })}>
                    <div ref='outerDiv' className={className}></div>
                </Measure>

[ragtime]

👍 for migration guide and the lib in general.

This is how we are currently using it:

<Measure whitelist={['height', 'width']}>
  { 
    ({width, height}) => (
      <Something
        width={width}
        height={height}
      />
    )
  }
</Measure>

[markwoon]

@souporserious A migration guide would have been a great help. Is there anything similar in v2 to whitelist? For example, I only care abound bounds.height and only want to be notified when that changes.

@estaub Assuming you're using ES6 class syntax, try

onResize = (contentRect) => {
  this.setState({ width: contentRect.bounds.width })};
};

render() {
  return (
<Measure bounds={true} onResize={this.onResize}>
{({measureRef}) => (
     <div ref={measureRef} className={className}></div>
)}
</Measure>
  );
}

[souporserious]

Thanks @markwoon! @estaub that should work for your example. If you need access to the ref you can do something like this:

<div
  ref={node => {
    this.outerDiv = node
    measureRef(node)
  }}
  className={className}
/>

I'm going to work on a guide as soon as I get a chance 😅

[markwoon]

@souporserious Could you also please elaborate more on using the withContectRect HOC? How would you use it with @estaub's example?

[estaub]

@markwoon I haven't tried your solution yet, but thanks; it appears to explain a problem I was having.

Re withContentRect, I found it eye-opening to read the source for <Measure>: https://github.com/souporserious/react-measure/blob/master/src/Measure.jsx

Read the last line carefully!

[estaub]

In starting to update the Typescript declarations, I read most of the implementation to figure out what's needed.

One area that I couldn't understand at all was the entry/entries feature in contentRect. What's it for, how's it used? I've no urgent need to know, I'm just saying it needs documenting if it's useful.

[souporserious]

withContentRect uses a ResizeObserver to detect changes. I believe the true width and height of the content is returned, as mentioned here in the spec. I have found things like getBoundingClientRect to work better in certain situations for some reason.

@que-etc might be able to help answer this better.