Make Trix compatible with morphing

[jorgemanrubia]

Morphing the trix editor will leave it in an unusuable state because morphing will replace the bootstrapping elements without triggering the connection logic.

The solution is based on adding an attribute to flag the editor as initialized and detect when that attribute is modified.

See hotwired/turbo-rails#533 (comment)

Pending:

• Tests

[jorgemanrubia]

@seanpdoyle I would love your eyes on the approach 🙏

[seanpdoyle]

Does this approach work with an existing <trix-toolbar> element? What about a <trix-editor> element with a [toolbar] attribute that references another element elsewhere in the page? Are the toolbars re-initialized as expected without attaching a duplicate?

[jorgemanrubia]

Good points, I'll see how to make these cases work. You are right that it will lose bootstrapped toolbars. I'll make sure it works well with both scenarios (existing toolbar and bootstrapped).

[jorgemanrubia]

I added some logic to (1) flag internal (bootstrapped) trix toolbars and (2) remove those when reconnecting. This works well in my test.s

[seanpdoyle]

I'd opened hotwired/turbo-rails#688 on the turbo-rails side to explore a different path toward support. I don't love it, and am skeptical that it's a complete solution. Having said that, sharing it here provides some additional context to the breadth of the problem.

[jorgemanrubia]

I'd opened hotwired/turbo-rails#688 on the turbo-rails side to explore a different path toward support. I don't love it, and am skeptical that it's a complete solution. Having said that, sharing it here provides some additional context to the breadth of the problem.

Thanks for the exploration @seanpdoyle. I prefer trying to fix this as the Trix level and keep the turbo Rails gem ignorant about this, as much as possible.

[seanpdoyle]

This line toggles the [internal-toolbar] attribute on the the <trix-editor> (since this references that element).

However, the removeInternalToolbar() function defined below checks this.toolbarElement (the <trix-toolbar> if the <trix-editor> element is using an "internal" toolbar).

Should this line set the attribute on the toolbar, or should the check be switched from this.toolbarElement to this?

[seanpdoyle]

Furthermore, is it important that the attribute be set? Could this same kind of internal state tracking be achieved by a JavaScript object property that isn't represented in the DOM?

[jorgemanrubia]

Ugh I think I messed that up when switching it to use toogleAttribute. I'll also make sure the tests catch this. Thanks 👍

[jorgemanrubia]

I fixed and used an internal attribute to grab the internal toolbar. That's better indeed. Also added another test for the case external toolbars.

[seanpdoyle]

While I think the naming of this attribute is ultimately an arbitrary implementation detail, I wonder if there are naming conventions that already exist that it could draw inspiration from.

For example, the <turbo-cable-stream-source> element that turbo-rails provides toggles an attribute named "connected" which mirrors the connectedCallback() hook and the Node.isConnected property.

[jorgemanrubia]

I like that. I renamed it to connected. It will also remove the attribute when disconnected. I also added a check to ensure the element is connected to the DOM before resetting the state when the attribute is removed.