Comments (11)
Hey there! I appreciate that! 🙏
It did cross my mind, but as small a task that may seem I think it won't happen in the near future, especially considering other higher-priority tasks.
The behavior of that hook is tested and ensured indirectly by the main hook's tests, which I'd have to replicate in the new package and then keep things in sync.
Honestly it's just not a complexity I'd be looking forward to with the very limited time I have all things considered. 😅
Where and how would you use it?
from use-resize-observer.
That's fair!
I have a couple hooks locally - some of them being replaced by useResizeObserver
now that our list of supported browsers is getting bumped - that use similar techniques to work with callback refs or refs or state and the implementation is not as thorough as yours. Given the limited scope of useResolvedElement
it feels like a great library to have and reuse.
from use-resize-observer.
Yeah I thought of that but then I'd have increased the API surface, which now I'd have to maintain.
I want the freedom to be able to freely refactor or even remove this hook altogether from source if it made sense in the future, so I'd much rather make it a package of its own right.
I'm a bit torn here to be honest, while I did make this internal hook to resolve a ref easily whether it's a:
- ref object passed through options,
- an element, or
- the ref callback being called,
I don't actually want to spread the pattern.
If I were to start over, I would only allow for an element option, or a ref callback, but not for a ref object.
There are all sorts of complexities that come from handling it because there's no way to know if .current is still up to date or not, and it doesn't allow for lazy-mounting.
Not sure if I'm making sense, just sort of dumped my thoughts. 😅
I get that a ref object is convenient, especially if you have many hooks depending on an element, as then you can go:
create ref object
hook1
hook2
hook3
jsx
Basically just passing the object to each hook.
But you actually lose correctness, and increase the chance of unexpected behaviour.
I'd much rather promote the concept of merging refs instead and avoid a class of potential issues, making the package in turn lighter as well. 🤷♂️
Not sure if that makes sense for you?
from use-resize-observer.
Oh also, I believe useResolvedElement
should use useLayoutEffect
otherwise the calculation of the size will happen after the browser has painted the component causing it to flash from one position to another.
from use-resize-observer.
Can you elaborate on that a bit?
useResolvedElement
is only resolving the html element to run RO with, it has nothing to do when or how size changes are reported? 🤔
from use-resize-observer.
@ZeeCoder I created a sandbox where the issue exists. When you click the button you should see a yellow box appearing and it should move right after being painted. Additionally if you see the console log, you should also see values 0
and 100
being printed.
The problem, I believe, is that useResolvedElement
resolves the DOM element after the browser has painted it, not giving us the possibility to position an element before that happens.
from use-resize-observer.
ooh so it's really about the first observation, right at mount.
Makes sense, could be a patch release for sure.
I'm in Portugal on a company trip rn, but I'll try to take a look as soon as I can next week. 👍
Thanks for the repro, efforts like these really make all the difference.
from use-resize-observer.
I'm in Portugal on a company trip rn, but I'll try to take a look as soon as I can next week. 👍
What a coincidence. That's where I'm living now.
Thanks for the repro, efforts like these really make all the difference.
Thanks! I wanted to open a PR but I have no idea how to test this behavior. I tried googling for a little bit and was unsuccessful, I might see if react has any interesting test about this behavior.
from use-resize-observer.
from use-resize-observer.
Sorry, I'm not able to help you in that front, but I welcome recommendations! 😜
from use-resize-observer.
I was wondering if we could expose useResolvedElement
from this package? Then you don't need a separate package, would be less useful for those only needing this hook since they would pull everything but it would at least allow others using this package to reuse useResolvedElement
.
from use-resize-observer.
Related Issues (20)
- Are the terms `blockSize` and `inlineSize` in the docs backwards? HOT 1
- Support for <img/> elements using `object-fit` HOT 5
- Future enhancement to return element coordinates
- Simply doesnt seem to want to work with a simple component. Crashes even in the simplest usage.
- SSR HTMLDivElement is not defined in 7.0.0 HOT 2
- Refs not being released on component dismounts leading to memory leaks HOT 7
- useResizeDetector resize method is not triggering in v7.0.1 HOT 7
- Using the same ResizeObserver instance for all hooks for better performance HOT 1
- Safari 15 has ResizeObserver API but it still does not work HOT 14
- ResizeObserverSize is not defined in typescript build
- onResize is not called on mount HOT 3
- Why is it suggested to instal as a dev dependency HOT 2
- No values reported when using React StrictMode HOT 5
- support for SVG elements HOT 9
- Basic usage is not working HOT 3
- Is there any reason we should save this as a dev dependency instead of a runtime dep? HOT 1
- Support getBoundingClientRect() HOT 9
- Question regarding environments missing ResizeObserver HOT 6
- export TS types HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from use-resize-observer.