Refactor `renderer.getClassList()` into `renderer.addClass()`, `renderer.removeClass()`

[caridy]

Function setScopeTokenClassIfNecessary calls getClassList(elm) on an element, and assumes the shape of the result value to be a DOM Object and calls .add() on it. Probably we should have a renderer api for just the add operation itself in one go.

[git2gus[bot]]

This issue has been linked to a new work item: W-11568519

[nolanlawson]

Rather than exposing the entire classList:

https://github.com/salesforce/lwc/blob/fda8d6f3d800ab5b883a88f086ab7656169f0d65/packages/%40lwc/engine-core/src/framework/renderer.ts#L45

... the renderer should have hooks to add or remove classes.

[nolanlawson]

I'm not sure this is entirely possible, because of this code:

https://github.com/salesforce/lwc/blob/2ddff92f4cb7c223e63a1ad791ae6b9bf2d66a42/packages/%40lwc/engine-core/src/framework/base-lightning-element.ts#L449-L466

We need to expose this.classList inside of a LightningElement, and to do that we need to have a getClassList on the renderer that returns the entire DOMTokenList.

[caridy]

Sure, but that doesn't mean we use that value to interact with, we just pass it along... then we can have new APIs just for the diffing. Basically, we have two separate buckets, APIs used for rendering, and APIs used for the element instance.

[nolanlawson]

@caridy What is the benefit in that case? We would have the following APIs on the renderer:

• getClassList
• addClass
• removeClass
• containsClass
• classListLength

(This is based on the APIs we actually use in the engine.)

If we expose getClassList anyway, it's not clear to me why we should have the other APIs as well.