[slottable-request] Given that `remove` is a short, common identifier, we may want to consider exposing this as a static symbol like `SlottableRequestEvent.remove`.

[Westbrook]

          Given that `remove` is a short, common identifier, we may want to consider exposing this as a static symbol like `SlottableRequestEvent.remove`.

Originally posted by @hunterloftis in #45 (comment)

[tbroyer]

Fwiw, currently it's defined as remove = Symbol('slottable-request-remove'), but that makes it non-interoperable between distinct implementations of the slottable-request protocol.

I think you meant to use remove = Symbol.for('slottable-request-remove') to share the same symbol over all implementations.

> Symbol("slottable-request-remove") === Symbol("slottable-request-remove")
// → false
> Symbol.for("slottable-request-remove") === Symbol.for("slottable-request-remove")
// → true

Similarly, using a static field meant to be used as SlottableRequestEvent.remove moves the concern to the implementation of the SlottableRequestEvent implementation being used by the consumer (which might not be the one of the event you're actually handling, used by the custom element).

This could be solved with either an instance field (if (event.data === event.remove)), a specific instance readonly property (if (event.remove)), or possibly a static field but documented as event.constructor.remove to be implementation-agnostic; or as said above using Symbol.for("slottable-request-remove")

[Westbrook]

Great catch. Happy to accept a PR on either the general naming or the symbol structure! 🙇🏼

[justinfagnani]

Yeah, the proposal currently defines this like there would be a common module that implementations could share. I think we'll want to do a pass to re-define things in terms of interfaces only. Symbol.for() is an improvement, but like a lot of DOM APIs, I think I'd probably prefer strings if they work.