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

useMeasure hook elements box-sizing option #1548

Open
m-kolomoyets opened this issue Apr 16, 2024 · 1 comment
Open

useMeasure hook elements box-sizing option #1548

m-kolomoyets opened this issue Apr 16, 2024 · 1 comment

Comments

@m-kolomoyets
Copy link

m-kolomoyets commented Apr 16, 2024

New Features

Current implementation of the useMeasure hook calculates the element bounds based on content-box model. It is a little unexpected behaviour when the project and all the layout is based on border-box model. Thus, current hook ignores paddings calculating element's width and height.

What is the new or updated feature that you are suggesting?

Suggesting adding the additional hook input parameter which has to define whether calculate content-box or border-box of the element.

Example of code calculating the border-box based content size:

//...
const [observerHandler] = useRafCallback<UseResizeObserverCallback>((entry) => {
    setMeasures({
        height: entry.borderBoxSize[0].blockSize,
        width: entry.borderBoxSize[0].inlineSize,
     });
});
// ...

And extend this logic into current calculation:

const [observerHandler] = useRafCallback<UseResizeObserverCallback>((entry) => {
    // For example:
    if (boxSizing === 'border-box') {
         setMeasures({
            height: entry.borderBoxSize[0].blockSize,
            width: entry.borderBoxSize[0].inlineSize,
         });
     } else {
         setMeasures({ width: entry.contentRect.width, height: entry.contentRect.height });
    }
});

Why should this feature be included?

Mostly border-box model is used, and content-box calculations are unexpected behaviour as expected to calculate the box-sizing model needed. Makes sense to add optional parameter to override the initial box-sizing model of the calculation to prevent unexpected miscalculations and debugging.

@xobotyi
Copy link
Contributor

xobotyi commented Nov 3, 2024

IMO it should be done the other way.
user must be able to provide matcher - function that matches captured ResizeObserverEntry to our height\width

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

No branches or pull requests

2 participants