Replace repetitive blurhash code with component

[brawaru]

This PR replaces all unnecessarily repeated code for decoding and embedding blurhash canvases with separate component — <Blurhash>.

Under the hood Blurhash component will use effect dependent on its props. This gives a few benefits: it will only be re-rendered whenever the hash or width/height/dummy props update, and will not render if canvas won't get to the final DOM, because then effect won't fire, which prevents weird bugs like #14257.

[brawaru]

Oh, this one went trough the merge conflicts resolution on rebase, check twice if I didn't remove something important!

[brawaru]

Since I imported React, I could have replaced this one with React, welp not a big deal to spin up CI again 🤦

Suggested change

	const canvasRef = /** @type {import('react').MutableRefObject<HTMLCanvasElement>} */ (useRef());
	const canvasRef = /** @type {React.MutableRefObject<HTMLCanvasElement>} */ (useRef());

[ClearlyClaire]

Not a proper review yet but: having a component for this would definitely make sense, however I'm not sure how good an idea it is to use functional-components-but-with-API-hooks style since we aren't using it anywhere else.

Furthermore, I think useEffect gets called later than componentDidMount and componentDidUpdate, so it might result in a slight delay before the canvas being drawn.

[brawaru]

@ThibG
however I'm not sure how good an idea it is to use functional-components-but-with-API-hooks style since we aren't using it anywhere else.

In my opinion functional components with hooks are easier to write, use and understand, unless they get too complex, in which case they can be split to more basic components and hooks abstracted under new hooks! The fact that many of Mastodon's components are written in class-like style doesn't mean all the new ones should too, especially those basic as this one.

In this example, if you would write this component using class, then you would have to, again: duplicate props checking, decoding calling and so on, here, however, you just useEffect which replaces need for two lifecycle methods (actually, useEffect may return a function which replaces componentDidUnmount), and has ability to check dependencies without you need to write if (prevProps newProps bla bla bla), you just pass an array and it does the job.

Furthermore, I think useEffect gets called later than componentDidMount and componentDidUpdate, so it might result in a slight delay before the canvas being drawn.

The only difference I may think of is that useEffect is asynchronous, other than this it is supposed to work just like componentDidMount and componentDidUpdate (?), I don't remember they had any difference in order they called. And if asynchronous call being a problem, there's always useLayoutEffect.

[ClearlyClaire]

I'm not arguing that functional components with hooks are worse in any way. I think they're fine, it's just a pretty different style to Mastodon's codebase and thus contributors would need to understand both. I'll defer to @Gargron for this.

The only difference I may think of is that useEffect is asynchronous, other than this it is supposed to work just like componentDidMount and componentDidUpdate (?), I don't remember they had any difference in order they called. And if asynchronous call being a problem, there's always useLayoutEffect.

According to https://en.reactjs.org/docs/hooks-reference.html#timing-of-effects:

Unlike componentDidMount and componentDidUpdate, the function passed to useEffect fires after layout and paint, during a deferred event. This makes it suitable for the many common side effects, like setting up subscriptions and event handlers, because most types of work shouldn’t block the browser from updating the screen.

useLayoutEffect could be more suitable indeed… though maybe we don't actually care if the blurhash isn't drawn immediately, idk

[brawaru]

it's just a pretty different style to Mastodon's codebase and thus contributors would need to understand both

That's why I think we should look into writing more new functional components with hooks and maybe rewriting some old new ones to also check for the bugs, so it won't be something extraordinary to see.

Talking about contributors

It's already really hard to wrap head around Mastodon code. When you see a functional component you might think “What kind of magic is happening there?”, you'll google a few methods that you don't know about, get to React docs, and it will teach you pretty much everything you needed to know to understand for the most part what this component is doing. You cannot really have this with classes, you have to learn of specific things like binding, lifecycle methods and such.

The benefit for contributors I think, is that is written in a readable manner, in a single function (maybe a few split functions), with understandable names (const onClick = useCallback, for example). It is probably much easier to maintain and change. Should note, however, such change won't help much contributors if we won't solve different problems with code, such as formatting (there is no styleguide and overall it's a disaster), code conventions and documentation… It's for another discussion.

though maybe we don't actually care if the blurhash isn't drawn immediately, idk

No flashes or whatsoever were seen when running on developer instance, even with CPU slowdown. I guess it's fine, if someone reports anything unusual we may look into it and change it to useLayoutEffect.

[ClearlyClaire]

What's this line about, exactly?

[brawaru]

It's HTML magic, whenever you use width/height setters on canvas, it will be completely reset, even if value does not change. It's used here in case (probably never will be the case, though) dummy prop changes, therefore canvas will be reset and left blank because of the return at the next line.

[ClearlyClaire]

I can't comment on the type annotations, as I don't know them, but otherwise this PR looks fine, provided @Gargron is ok with the functional-with-hooks style.

[ykzts]

I think functional components with hooks that are simple to write are good.

In addition, I confirmed the type annotations.