Reactive DOMRect

[Azarattum]

Describe the problem

DOMRect is a super convenient native API to represent rectangular shapes (not only DOM ones). I encountered a situation where I needed to create a reactive rect, but found out that it is missing from svelte/reactivity. I think it would be a really nice addition to the reactivity package.

Describe the proposed solution

It could look something like this:

import { SvelteDOMRect } from "svelte/reactivity";

const rect = new SvelteDOMRect();
$inspect(rect.left); // init 0; update 100
$inspect(rect.right); // init 0; update 200

setTimeout(() => {
  rect.x = 100;
  rect.width = 100;
});

If somebody from the maintainers approves this feature, I can make a PR.

Importance

would make my life easier

[paoloricciuti]

Maybe I'm missing something but how a framework provided implementation would differ from

class Rect{
    width=$state();
    height=$state();
    x=$state();
    y=$state();
}

Where do we cut the line for things that the framework provides?

[Conduitry]

I think the difference would be the computed top/right/bottom/left properties - not that that by itself would be sufficient reason to implement this.

[paoloricciuti]

I think the difference would be the computed top/right/bottom/left properties - not that that by itself would be sufficient reason to implement this.

Oh gotcha...missed that

[Azarattum]

not that that by itself would be sufficient reason to implement this.

Isn't URL also just a bunch of computed properties?

Of course it can be implemented in userland, but so are the other reactive helpers. I feel like DOMRect is common enough to also be a built-in.

[paoloricciuti]

not that that by itself would be sufficient reason to implement this.

Isn't URL also just a bunch of computed properties?

Of course it can be implemented in userland, but so are the other reactive helpers. I feel like DOMRect is common enough to also be a built-in.

I think the interesting bit about url is searchParams.get()

[7nik]

I don't feel like we need this: it is simple to implement on the user land, and I barely have seen usage of even static DOMRect. Some classes are often used in certain cases, but it doesn't they are widely used.

[rChaoz]

What if it also came with an additional binding?

<div bind:boundingClientRect={domRect}>...</div>

There already are bindings for other dimensions like client/offset width/height... DOM rect is more commonly used and this would be a very nice addition.

[Azarattum]

There already are bindings for other dimensions like client/offset width/height... DOM rect is more commonly used and this would be a very nice addition.

This would be awesome. However this is really tricky to implement right. Sure, you can react to size changes with ResizeObserver, but boundingClientRect also has a screen-relative position of an element that depends on a lot of factors (e.g. scrolling). And you obviously wouldn't want to measure it on each frame during scroll.

In my case I need to measure positions of some elements relative to each other, so that takes scroll and many other factors out of the equation. Which is why I'm using ResizeObserver + getBoundingClientRect combo which works in my case (I cannot you just ResizeObserver since it doesn't returns the position at all...). So, here have arisen my need for a reactive DOMRect, since I would not want to update an entire object every time (leading to unnecessary rerenders/computations). And using a POJO you lose the relationship between x, width -- left, right etc. I could have just implemented it myself and moved on. Though I thought it might be common/useful enough to implement in the framework itself, so I've open this issue and suggested to make a PR.

[nmzein]

Yeah see #13412. Theres basically no way to correctly get boundingClientRect without polling. Would love for there to be a better browser api for this like PositionObserver or smth but there isnt unfortunately.