perf: optimize initial render for nullish class

[nolanlawson]

Details

From looking at our Best benchmarks, I realized we had actually regressed recently in dom-table-hydrate-1k due to #3950:

Tachometer confirmed it (comparing current master to the 250 release, i.e. v6.4.5):

The reason is actually unrelated to hydration – it's because the components used in this benchmark set a class to row.className which is actually undefined:

lwc/packages/@lwc/perf-benchmarks-components/src/benchmark/table/table.html

Line 11 in c1f4a2b

<tr key={row.id} class={row.className}>

After #3950, the ncls utility is converting undefined into an empty string:

lwc/packages/@lwc/engine-core/src/framework/api.ts

Lines 747 to 748 in c1f4a2b

	function ncls(value: unknown): string {
	let res = '';

lwc/packages/@lwc/engine-core/src/framework/api.ts

Line 770 in c1f4a2b

return StringTrim.call(res);

This means we don't hit the early-return condition when patching the class attribute:

lwc/packages/@lwc/engine-core/src/framework/modules/computed-class-attr.ts

Lines 70 to 73 in c1f4a2b

	const oldClass = isNull(oldVnode) ? undefined : oldVnode.data.className;
	if (oldClass === newClass) {
	return;
	}

This PR fixes this, by converting undefined and null into undefined within ncls, which means we hit the early-return when patching classes. This fixes the perf regression in the benchmark (comparing this PR to master):

There are probably more optimizations we can do to ncls (e.g. treating '' the same as undefined, avoiding the StringTrim call), but this PR is at least a start.

Does this pull request introduce a breaking change?

• 😮‍💨 No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• 🤞 No, it does not introduce an observable change.

The engine ultimately treats a null, undefined, or "" class exactly the same at runtime, so there are no observable changes.

[jmsjtu]

Nice find! 😄 LGTM