Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add hooks to integrate with Action Text #688

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

seanpdoyle
Copy link
Contributor

One major challenge that applications face when integrating with morphing-powered Page Refreshes involves <trix-editor> elements rendered by Action Text.

The emergent guidance instructs applications to skip morphing by marking the <trix-editor> as permanent. This guidance, while correct, does not encapsulate the entire story. In the case of Action Text-rendered <trix-editor> elements, applications might invoke form.rich_text_area with data: {turbo_permanent: true}, expecting for the presence of trix-editor[data-turbo-permanent] to be sufficient.

However, to achieve the intended behavior, applications must nest their <trix-editor> elements within an element with [data-turbo-permanent] (a <div>, a <fieldset>, etc.). This provides a container for the trix-editor to inject its associated <input> and <trix-toolbar> elements. A <trix-editor> element will insert an <input type="hidden"> element and a <trix-toolbar> element when they are absent on connect.

Applications can skip a Trix-manage injection by rendering those either (or both) elements ahead of time, then associating them to the trix-editor through [input] and [toolbar] attributes (respectively).

Action Text skips the <input> injection step by rendering and associating an Action View-rendered <input type="hidden"> attribute with the appropriate attributes.

No matter how the <input> connects to the document, it's important for it to keep its [data-turbo-permanent] synchronized with the trix-editor's attribute in order to tolerate a morph.

Since Page Refreshes, Morphing, and permanence are all Turbo concepts, and Action Text is a Rails framework, turbo-rails feels like the most appropriate codebase (out of rails, trix, turbo, and turbo-rails) to house the integration.

@seanpdoyle seanpdoyle force-pushed the actiontext-integration branch 2 times, most recently from 389a30f to 93fbd3d Compare September 30, 2024 16:52
One major challenge that applications face when integrating with
morphing-powered Page Refreshes involves `<trix-editor>` elements
rendered by Action Text.

The emergent guidance instructs applications to skip morphing by
marking the `<trix-editor>` as permanent. This guidance, while correct,
does not encapsulate the entire story. In the case of Action
Text-rendered `<trix-editor>` elements, applications might invoke
`form.rich_text_area` with `data: {turbo_permanent: true}`, expecting
for the presence of `trix-editor[data-turbo-permanent]` to be
sufficient.

However, to achieve the intended behavior, applications must *nest*
their `<trix-editor>` elements *within* an element with
`[data-turbo-permanent]` (a `<div>`, a `<fieldset>`, etc.). This
provides a container for the `trix-editor` to inject its associated
`<input>` and `<trix-toolbar>` elements. A `<trix-editor>` element will
insert an `<input type="hidden">` element and a `<trix-toolbar>` element
when they are absent on connect.

Applications can skip a Trix-manage injection by rendering those
either (or both) elements ahead of time, then associating them to the
`trix-editor` through `[input]` and `[toolbar]` attributes
(respectively).

Action Text skips the `<input>` injection step by rendering and
associating an Action View-rendered `<input type="hidden">` attribute
with the appropriate attributes.

No matter how the `<input>` connects to the document, it's important for
it to keep its `[data-turbo-permanent]` synchronized with the
`trix-editor`'s attribute in order to tolerate a morph.

Since Page Refreshes, Morphing, and permanence are all Turbo concepts,
and Action Text is a Rails framework, `turbo-rails` feels like the most
appropriate codebase (out of `rails`, `trix`, `turbo`, and
`turbo-rails`) to house the integration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant