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

Delegate StreamActions.refresh to Session #1026

Conversation

seanpdoyle
Copy link
Contributor

The bulk of the StreamActions.refresh implementation was reaching
through the global window.Turbo property, which itself was reaching
through either global variables or the Session.

This commit moves the implementation out of the StreamActions and into
a new Session.refresh(url, requestId) method. With that change, all
property access is encapsulated within the Session.

To support that change, this commit also introduces the
StreamElement.requestId property to read the [request-id] attribute.

@seanpdoyle seanpdoyle mentioned this pull request Oct 8, 2023
2 tasks
@seanpdoyle seanpdoyle changed the title Delegate StreamActions.refresh to Session Delegate StreamActions.refresh to Session Oct 9, 2023
@jorgemanrubia jorgemanrubia force-pushed the morph-refreshes branch 3 times, most recently from 7ac1faf to d1935bd Compare October 23, 2023 09:24
The bulk of the `StreamActions.refresh` implementation was reaching
through the global `window.Turbo` property, which itself was reaching
through either global variables or the `Session`.

This commit moves the implementation out of the `StreamActions` and into
a new `Session.refresh(url, requestId)` method. With that change, all
property access is encapsulated within the `Session`.

To support that change, this commit also introduces the
`StreamElement.requestId` property to read the `[request-id]` attribute.
@seanpdoyle seanpdoyle force-pushed the morph-refreshes-session-refresh-method branch from 2d40294 to 0bfb97e Compare October 23, 2023 15:11
@afcapel afcapel merged commit 0e2081f into hotwired:morph-refreshes Oct 24, 2023
1 check passed
@afcapel
Copy link
Collaborator

afcapel commented Oct 24, 2023

Makes sense, thanks @seanpdoyle 👍

@seanpdoyle seanpdoyle deleted the morph-refreshes-session-refresh-method branch October 24, 2023 10:41
jorgemanrubia pushed a commit that referenced this pull request Oct 27, 2023
The bulk of the `StreamActions.refresh` implementation was reaching
through the global `window.Turbo` property, which itself was reaching
through either global variables or the `Session`.

This commit moves the implementation out of the `StreamActions` and into
a new `Session.refresh(url, requestId)` method. With that change, all
property access is encapsulated within the `Session`.

To support that change, this commit also introduces the
`StreamElement.requestId` property to read the `[request-id]` attribute.
@afcapel
Copy link
Collaborator

afcapel commented Oct 27, 2023

@seanpdoyle I just noticed that this commit introduced a circular dependency.

mbp 3.2.0 ~/Work/hotwired/turbo (ce4a2be...) yarn build
yarn run v1.22.19
$ rollup -c

src/index.js → dist/turbo.es2017-umd.js, dist/turbo.es2017-esm.js...
(!) Circular dependency
src/core/index.js -> src/core/streams/stream_actions.js -> src/core/index.js
created dist/turbo.es2017-umd.js, dist/turbo.es2017-esm.js in 345ms
✨  Done in 0.91s.

I'm going to temporarily revert the commit, but feel free to reopen a new PR without the circular dependency.

@seanpdoyle
Copy link
Contributor Author

@afcapel I believe the circular dependency was re-introduced in response to https://github.com/hotwired/turbo/pull/1023/files#diff-dacdc6fe4d4b16718a923a226357e7750053bf3636e627ea06cff12345362137. I think that removing the StreamActions was important in making this change.

@seanpdoyle
Copy link
Contributor Author

@afcapel I've confirmed locally that the circular dependency isn't mentioned during builds with this change:

diff --git a/src/core/index.js b/src/core/index.js
index b2ada17..27a2ad1 100644
--- a/src/core/index.js
+++ b/src/core/index.js
@@ -9,8 +9,6 @@ const session = new Session()
 const { cache, navigator } = session
 export { navigator, session, cache, PageRenderer, PageSnapshot, FrameRenderer, fetch }
 
-export { StreamActions } from "./streams/stream_actions"
-
 /**
  * Starts the main session.
  * This initialises any necessary observers such as those to monitor
diff --git a/src/index.js b/src/index.js
index 07e3e09..c3f2787 100644
--- a/src/index.js
+++ b/src/index.js
@@ -7,6 +7,7 @@ import * as Turbo from "./core"
 window.Turbo = Turbo
 Turbo.start()
 
+export { StreamActions } from "./core/streams/stream_actions"
 export * from "./core"
 export * from "./elements"
 export * from "./http"

seanpdoyle added a commit to seanpdoyle/turbo that referenced this pull request Oct 27, 2023
@seanpdoyle
Copy link
Contributor Author

I've opened #1049.

afcapel pushed a commit that referenced this pull request Oct 27, 2023
@afcapel
Copy link
Collaborator

afcapel commented Oct 27, 2023

Merged!

jorgemanrubia pushed a commit that referenced this pull request Nov 6, 2023
The bulk of the `StreamActions.refresh` implementation was reaching
through the global `window.Turbo` property, which itself was reaching
through either global variables or the `Session`.

This commit moves the implementation out of the `StreamActions` and into
a new `Session.refresh(url, requestId)` method. With that change, all
property access is encapsulated within the `Session`.

To support that change, this commit also introduces the
`StreamElement.requestId` property to read the `[request-id]` attribute.
jorgemanrubia pushed a commit that referenced this pull request Nov 6, 2023
afcapel added a commit that referenced this pull request Nov 14, 2023
* Page refreshes

This commit introduces the concept of page refresh. A page refresh
happens when Turbo renders the current page again. We will offer two new
options to control behavior when a page refresh happens:

- The method used to update the page: with a new option to use morphing
  (Turbo currently replaces the body).

- The scroll strategy: with a new option to keep it (Turbo currently
  resets scroll to the top-left).

The combination of morphing and scroll-keeping results in smoother
updates that keep the screen state. For example, this will keep both
horizontal and vertical scroll, the focus, the text selection, CSS
transition states, etc.

We will also introduce a new turbo stream action that, when broadcasted,
will request a page refresh. This will offer a simplified alternative
to fine-grained broadcasted turbo-stream actions.

Co-Authored-By: Jorge Manrubia <jorge@hey.com>

* Introduce refresh attribute for frame element

* Use dispatch util function in MorphRenderer

* Don't morph frames flagged with "refresh=morph" as part of the full page refresh

We will refresh those frames with morphing as part of the page refresh, so it does
not make sense to morph them also as part of the full page refresh. If we do, we'll
trigger a manual reload because the complete attribute will get removed. This aligns
the upstreamed version with the private gem we've been using internally.

This also fixes a couple of issues:

- We don't want to manually reload all the remote turbo-frames, only those that are
flagged with "refresh=morph". Regular remote frames will get reloaded automatically
when removing their complete attribute during regular page refreshes.

- Using idiomorph's "innerHTML" was resulting in a turbo-frame nested inside the
target turbo-frame. I think its semantics is not morphing inner contents from both
currentElement and newElement, but morphing newElement as the inner contents of currentElement.

See #1019 (comment)

* Delegate `StreamActions.refresh` to `Session` (#1026)

The bulk of the `StreamActions.refresh` implementation was reaching
through the global `window.Turbo` property, which itself was reaching
through either global variables or the `Session`.

This commit moves the implementation out of the `StreamActions` and into
a new `Session.refresh(url, requestId)` method. With that change, all
property access is encapsulated within the `Session`.

To support that change, this commit also introduces the
`StreamElement.requestId` property to read the `[request-id]` attribute.

* Only morph the turbo-frame contents, not the frame itself

I had removed this in #d1935bd15c85e0a8776afccb90393fd378aea2d2 but we do
need innerHTML so that the outer frame don't get touched. The problem we had
is that we were nesting turbo-frames, so using .children to only address the
contents instead.

* Don't patch fetch globally, import patched function where needed instead.

We'll export a `fetch` function apps can import too. This can be necessary if an app,
for example, is doing a manual `fetch` and it wants to prevent a reflected broadcast
triggered by that request.

We'll also make rails/request use the Turbo fetch version when available. That will be
the preferred form. In general, we don't want apps to care about having to import or
use Turbo's `fetch`, but it will be available for the cases an app needs it.

We'll also expose the patched version via `Turbo.fetch`.

See discussion #1019 (review)

* Always morph remote turbo-frames when a page refresh happens

Instead of flagging the frames you want to morph with an special attribute,
we are always going to reload and refresh with morphing all the turbo-frames
in the page.

This simplifies the API as it removes the concern of categorizing remote
turbo-frames on the programmer side when using page-refreshes.

This is an idea by @afcapel, who raised the concern of the confusion the attribute
replace=morph caused, and questioned its necessity.

We can bring the old approach back if we find real cases that justify it.

* Remove Circular Build Dependency (#1049)

Resolves #1026 (comment)

* Don't refresh automatically turbo-frames that descend from a [data-turbo-permanent] element

Since we are now reloading all the remote frames in the page, we need to make sure we ignore
those that are contained in elements to be preserved.

* Don't add new [data-turbo-permanent] elements when they already exist in the page.

It can happen that a same element exists but that idiomorph won't match it
because some JS moved the element to another position. This will handle such
scenarios automatically.

* Don't reload stimulus controllers after morphing

There was a flaw in the implementation: we wanted to reload the stimulus controllers
when their element was effectively morphed because some attribute had changed. Our
implementation was essentially reloading all the stimulus controllers instead.

But, even if we implemented our original idea, we have changed our mind about it being
the right call. The heuristic of "reload controllers when some attribute changed" came
from some tests with legacy controllers that used dom attributes to track certain
conditions. That doesn't seem like enough justification for the original idea.

In general, you don't want to reload controllers unless their elements get disconnected
or connected as part of the morphing operation. If it's important for a given controller
to track changes to the dom, than it should do that (e.g: listening to connection of targets or
outlets, or just with the mutation observer API), but we can't determine that from the outside.

If we introduce some API here, it will be the opposite: an API to force a "reconnect" during
morphing, but we need to see a real justification in practice.

* Respect morphing and scroll preservation settings when handling form errors

Turbo will render 422 responses to allow handling form errors. A common scenario
in Rails is to render those setting the satus like:

```
render "edit", status: :unprocessable_entity
```

This change will consider such operations a "page refresh" and will also consider
the scroll directive.

* Morph remote turbo frames where the src attribute has changed

There are some cases when we don't want to reload a remote turbo frame on
a page refresh.

This may be because Turbo has added a src attribute to the turbo frame
element, but we don't want to reload the frame from that URL.

Form example, when a form inside a turbo frame is submitted, Turbo adds
a src attribute to the form element. In those cases we don't want to
reload the Turbo frame from the src URL. The src attribute points to the
form submission URL, which may not be loadable with a GET request.

Same thing can happen when a link inside a turbo frame is clicked. Turbo
adds a src attribute to the frame element, but we don't want to reload the
frame from that URL.

If the src attribute of a turbo frame changes, this signals that the server
wants to render something different that what's currently on the DOM, and
Turbo should respect that.

This also matches the progressive enhancement behavior philosophy of Turbo.
The behaviour results in the Turbo frame that the server sends, which
is what would happen anyway if there was no morphing involved, or on a first
page load.

---------

Co-authored-by: Jorge Manrubia <jorge@hey.com>
Co-authored-by: Sean Doyle <seanpdoyle@users.noreply.github.com>
Co-authored-by: Jorge Manrubia <jorge.manrubia@gmail.com>
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.

None yet

2 participants