Should I use memo?

[rejhgadellaa]

If I have a component that I'm pretty sure should only update when the props change, should I wrap it in memo?

I'm asking because it's located in compat, not in the core, so I'm wondering if Preact has optimizations in place that make memo (more or less) redundant and the addition is just to support the React api?

[rschristian]

You can use it, sure.

To paraphrase Marvin, it's in preact/compat as we think it's not a great API, comparatively. Signals are a much more attractive approach for dealing with unnecessary rerenders, and goes a lot further than memo does. We don't have memo in core because we don't think it's an essential piece, not because it doesn't serve a purpose.

[rschristian]

Signals themselves are "memoized" (I use this to refer more to the end result/DX than traditional React-flavor memoization) and only update that which subscribes to them. The concept of memoizing components is therefore redundant & unnecessary.

memo is needed to avoid doing additional work when props don't change but signals simply don't trigger that work in the first place. Full component rerenders no longer occur.

[pkamenarsky]

So then why use Preact in the first place (instead of say, SolidJS, which is centered around signals and doesn't export a React style API at all)?

Signals are conceptually harder to deal with than immutable data (for example, undo/redo is basically one line of code; try to do the same with signals buried deep down in some data structure).

Why incur an extra dependency for such a fundamental primitive like memo?

[rschristian]

preact/compat isn't a separate dependency, it's a subpath export of preact, and we simply don't find memo to be a fundamental primitive. Anecdotally, it's an API that's pretty uncommonly reached for these days. I don't see too many teams reaching for or using it.

But, if you prefer Solid, you're more than welcome to use it. It's a great tool.

Signals are conceptually harder to deal with than immutable data

That's quite subjective and many disagree. Personally, I don't find immutable data any easier to deal or reason with, just more typing to work around.

[pkamenarsky]

preact/compat isn't a separate dependency

I didn't realize that! Perfect.

But, if you prefer Solid, you're more than welcome to use it. It's a great tool.

It is, but I am actually rewriting an app from Solid to Preact precisely because I find signals to be harder to deal with than immutable data. What I meant is (and I realize I wasn't clear enough) is that signals are more or less Solid's niche - and it is surprising to see them presented as the preferred way to organize state in Preact, which (at least some time ago) was presented as a lightweight drop-in replacement to no-signals React.

All is good, and thanks for the quick reply!

[rschristian]

Fair enough!

Benefit of Preact's architecture is that we can pretty easily support signals and a React-like API, we don't have to pick one or the other.

A lot of people really, really struggle to use React API's correctly (hence all those required linter plugins) and so we're pushing signals a bit here as they are generally far simpler for people to understand.

If you don't want it then that's a-ok and most of the React APIs are there as alternatives.