useResizeObserver ref type aligned with useRef

[troyspencer]

MutableRefObject is what useRef returns. With this change, the refs are interchangeable.
This also allows it to be placed on more elements without TypeScript complaining. Solves #12

[ZeeCoder]

I'm sorry I didn't answer for so long, I'm quite busy with work / personal life stuff at the moment and as I don't know TypeScript I have no way to confirm this change.

Could you recommend articles / docs where I could confirm what it means that you did here?

I need to up my TypeScript game at some point anyway 😅

[henrycatalinismith]

Came here after Googling this error:

Error

Type 'RefObject' is not assignable to type 'string | ((instance: HTMLDivElement | null) => void) | RefObject | null | undefined'. Type 'RefObject' is not assignable to type 'RefObject'. Property 'align' is missing in type 'HTMLElement' but required in type 'HTMLDivElement'.ts(2322) index.d.ts(87, 9): The expected type comes from property 'ref' which is declared here on type 'DetailedHTMLProps, HTMLDivElement>'

Screenshot

Then I made the following change to my use-resize-observer call after reading the diff of this PR:

-const [ref, width, height] = useResizeObserver()
+const [ref, width, height] = useResizeObserver() as [MutableRefObject<any>, number, number]

I haven't spent any time understanding this at any deeper level, but it's made my error go away! 😆

[ZeeCoder]

I'm actually thinking of just removing TS support now. 🤷‍♂️
Maybe in the future I might try rewriting the source, but the need of maintaining types without knowing the language is already stopping me from updating this lib. 😅

[troyspencer]

The PR works, it fixes the issue I referenced. It does so in the typing source, rather than being patched upon usage. The original typing was wrong, and too restrictive to the intended elements to place it on.

[ZeeCoder]

I'd rather just not bother with types as I have no way of ensuring they're right.
From my point of view, someone else could come along in a week's time, claiming that your changes were not right either. 🤷‍♂️

Not to mention it's blocking changes I would've released ages ago otherwise:
#10

[troyspencer]

I've got my fork, have fun over here then

[ZeeCoder]

It's annoying that TS would force you to fork a lib like this.
Wonder if Flow does the same or if it's more forgiving.

[troyspencer]

TS isn't what forced the fork, making a PR to fix an issue did that. But the maintainer removing TS because learning is hard, and forcing solutions like hencatsmith did above is a good reason continue using that fork, and not look back on this repo.

[ZeeCoder]

Ugh, sorry that I made you do all that effort, must've been horrible, I can't imagine the hours you must've spent on it. 🙄

"learning is hard"
Yeah, sure that was it. 🤦‍♂️

Can't believe even at this level people get annoyed when the maintainer doesn't do exactly what they want with a lib he spent countless hours on already.

Have fun with your fork of free code, I have no time for such toxicity in my life.