Things like this make me wonder whether we should ship a "development" and a "production" version. I remember the discussions about making things more complex bundling wise but couldn't we omit this line in a "production" or "minimal" variant of our build? That would save us some bytes here and there.

Or are we somehow able to move this line to debug? I though about monkey patching the exported function but that only works in CJS and not ESM AFAIK.

I was pondering this. There's no usable way to ship debug variants today, and we get a lot of value out of avoiding pushing that stuff onto users. But I think there may be a compromise solution possible: preact/debug can actually set this on its own:

// memo.js
Memoed.displayName = 'Memo(';

// forwardRef.js
Forwarded.displayName = 'forwardRef(';

import { options } from 'preact';

options.vnode = (vnode) => {
  if (typeof vnode.type === 'function') {
    // turn "Memo(" into "Memo(ChildName)" the first time we see a constructor
    if (/\(/.test(vnode.type.displayName)) {
      const child = vnode.type.call({}).type;
      vnode.type.displayName += (child.displayName || child.name) + ')';
    }
  }
};

It would require us striping forwardRef and memo out of compat if I'm reading that correctly, right?

@marvinhagemeister I'd hoped the above would avoid that - instead of relying on vnode.type === Memo, it uses the (-suffixed name as an indication that displayName should be regenerated to include the child component's displayName.

This is probably a non-zero perf hit in preact/debug though, with or without compat enabled. Might not be worth it.

What is the reason for dropping this? Would save us 2 bytes keeping the let _this = this and using _this afterwards

yeah I was 50/50 on this. I think some more refactoring can get the total down, but the _this alias was masking some of the other possible changes. I was mostly just trying to switch out arrow functions that had the possibility to cause accidental closures for this access.

I'm curious if anyone is opposed to this change. It means we would be using setAttribute("class") for a class prop and .className= for a className prop. They're the same thing, but it's possible there's a performance difference.