Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new super-powerful API idea #70

Open
jedwards1211 opened this issue Jul 14, 2017 · 5 comments
Open

new super-powerful API idea #70

jedwards1211 opened this issue Jul 14, 2017 · 5 comments

Comments

@jedwards1211
Copy link

Hi @souporserious,

The idea of passing a measureRef to the child function was genius, and it made me realize we could do something similar to make it possible for a single <Measure> element to measure many components in one fell swoop.

The idea is to turn measureRef into a function that we call with what to measure and the name of a state subtree, and then it returns a ref. So we can create as many refs as we need inside the child function:

<Measure>
  {({measureRef, root, top, bottom}) => (
    <div ref={measureRef('root', {offset: true})}>
      My offset rect is {root.offset}
      <div ref={measureRef('top', {bounds: true})}>
        My bounds are {top.bounds}
      </div>
      <div ref={measureRef('bottom', {offset: true, scroll: true})}>
        My offset rect is {bottom.offset}
        My scroll rect is {bottom.scroll}
      </div>
    </div>
  )}
</Measure>

The other advantages of this API are:

  • It could provide all of the DOM measurements in a single state update
  • All of the measurements can easily be used anywhere inside the child render function (whereas with the current API one would have to manually put all the measurements on their component's own state)
@souporserious
Copy link
Owner

This is great! I had a similar idea when I introduced it 😆 but I wasn't sure how I could make the API work. I need to explore some things further, but I love the start of this! I'd love to be able to handle multiple measurements in one pass if possible. I might start looking at a 3.0 release here soon. I think after seeing some of these issues, there's a nice path forward for a powerful measurement API.

@jedwards1211
Copy link
Author

Sweet! Do you think it would cause any difficulties with attaching or detaching the resize observers?

@souporserious
Copy link
Owner

I don't think so! My initial idea for this was sparked by ResizeObservers being able to take multiple entries, so I just need to explore that a little more :) Essentially, I think you would have one ResizeObserver for the component and then each function call could subscribe to it. Then if the ref returns null it can unsubscribe.

@jedwards1211
Copy link
Author

huh, I still don't know much about ResizeObservers. Anyway that's cool!

@souporserious
Copy link
Owner

Finally got around to this if you're interested in trying out the release candidate 😸 #97.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants