Refresh main page after modal was closed by the user

[frenkel]

My main page doesn't update automatically. When a user clicks an item, makes some changes there and then drags the modal down to close it there will be outdated information on the page. How can I refresh the main page? I tried different things with presentation": "refresh" but that didn't seem to work or broke my modal opening completely.

My current path-configuration.json:

{
  "settings": {},
  "rules": [
    {
      "patterns": [
        ".*"
      ],
      "properties": {
        "context": "default",
        "pull_to_refresh_enabled": true,
        // screen stays black when this is enabled:
        // "presentation": "refresh"
      }
    },
    {
      "patterns": [
        "/my-item-path-pattern"
      ],
      "properties": {
        "context": "modal",
        "pull_to_refresh_enabled": false,
         // enabling this breaks the modal open and stays on the same page:
         // "presentation": "refresh"
      }
    }
  ]
}

[joemasilotti]

If the "changes" made in the modal use non-GET requests then they should bust the snapshot cache. Then, when the modal is dismissed, the page showing underneath with automatically reload.

[frenkel]

Yes I did.

[joemasilotti]

Darn. Can you try making a non-JS non-GET request in the modal and see if that works? Just to test.

Or, if you could work this into the demo app somehow so I can reproduce and debug that would be super helpful.

[frenkel]

Thanks for investigating!

I've created a sample Rails app with an index page that shows the current time. When you click the show page link it will open in a modal. The modal contains a form that does a patch request. After clicking the button, you can drag the modal down and will see the index is not refreshed.

Schermopname.2025-08-13.om.08.52.27.mov

https://github.com/frenkel/close-modal
https://github.com/frenkel/close-modal-app

[joemasilotti]

Thanks! That's super helpful.

Long story short, you can fix your issue by making the modal "full screen", like so.

diff --git a/close-modal-app/AppDelegate.swift b/close-modal-app/AppDelegate.swift
index 6abb6c8..f1e01f0 100644
--- a/close-modal-app/AppDelegate.swift
+++ b/close-modal-app/AppDelegate.swift
@@ -20,6 +20,8 @@ class AppDelegate: UIResponder, UIApplicationDelegate {
             .file(localPathConfigURL),
         ])

+        Hotwire.config.showDoneButtonOnModals = true
+
         return true
     }

diff --git a/close-modal-app/path-configuration.json b/close-modal-app/path-configuration.json
index 3d5af3b..83a3dd0 100644
--- a/close-modal-app/path-configuration.json
+++ b/close-modal-app/path-configuration.json
@@ -16,6 +16,7 @@
       ],
       "properties": {
         "context": "modal",
+        "modal_style": "full",
         "pull_to_refresh_enabled": false
       }
     }

This also adds a Done button to all modals to ensure users can dismiss the modal.

Long explanation follows :)

---

Under the hood, the PATCH request is correctly triggering the form submission callbacks. The snapshot cache for the main Session is also being correctly marked as stale.

extension Navigator: SessionDelegate {
    public func sessionDidFinishFormSubmission(_ session: Session) {
        if session == modalSession {
            self.session.markSnapshotCacheAsStale() // <--- Correctly being called.
        }
        if let url = session.topmostVisitable?.initialVisitableURL {
            delegate?.formSubmissionDidFinish(at: url)
        }
    }
}

Then, when the Visitable appears, Session.visitableViewWillAppear(_:) should get called.

extension Session: VisitableDelegate {
    public func visitableViewWillAppear(_ visitable: Visitable) {
        // ...

        if isSnapshotCacheStale { // <--- true
            clearSnapshotCache()
            isSnapshotCacheStale = false
        }

        // ...
    }
}

This should be triggered when VisitableViewController overwrites UIViewController.viewWillAppear(_:):

open class VisitableViewController: UIViewController, Visitable {
    // ...

    override open func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        if appearReason == .tabSelected { return }
        visitableDelegate?.visitableViewWillAppear(self)
    }
    
    // ...
}

However, a default-sized (non-full screen) modal does not call this lifecycle method! So even though the content is marked as stale, Hotwire Native never gets a chance to tell it to refresh.

This is expected behavior, as seen in the documentation:

Where the background content remains visible, the system doesn’t call the presenting view controller’s viewWillDisappear(_:) and viewDidDisappear(_:) methods.

Also of note, the "fix" above works because of another potential issue. When dismissing a full-screen modal this will always perform this restoration visit, even if a non-GET request was not made in the modal!

extension Session: VisitableDelegate {
    public func visitableViewWillAppear(_ visitable: Visitable) {
        // ...

        // Navigating backward from a native to a web view screen.
        if visitable === previousVisit?.visitable { // <--- true
            visit(visitable, action: .restore) // <--- "Refreshes" the view via restore.
        }
    }
}

@svara, can you please confirm if this is correct? If so, we will most likely want to rethink our handling of views appearing to trigger reloads. Thanks for bringing this up, @frenkel!

Assuming we fix the viewWillAppear(_:) issue, I'd love to add the following line to cause the presenting view controller to automatically reload when it appears:

diff --git a/Source/Turbo/Navigator/Navigator.swift b/Source/Turbo/Navigator/Navigator.swift
index 8456a63..d839166 100644
--- a/Source/Turbo/Navigator/Navigator.swift
+++ b/Source/Turbo/Navigator/Navigator.swift
@@ -198,6 +198,7 @@ extension Navigator: SessionDelegate {
     public func sessionDidFinishFormSubmission(_ session: Session) {
         if session == modalSession {
             self.session.markSnapshotCacheAsStale()
+            self.session.markContentAsStale()
         }
         if let url = session.topmostVisitable?.initialVisitableURL {
             delegate?.formSubmissionDidFinish(at: url)

[frenkel]

Thanks for this thorough examination and explanation! Your solution works indeed. If I understand you correctly your proposed change to Hotwire Native would also fix this without the need for a fullscreen modal, right? Let's hope everyone agrees it is needed so both modals would work correctly.

[domchristie]

I also ran into this issue and have been looking into a viable solution, mainly from the front-end perspective. So here's another (less-than-ideal) approach, but it might spark some ideas…

The idea is to create a BroadcastChannel then enables communication between the main webview and the modal webview. Then, override Turbo.cache.clear to post a message on the channel when the cache has been cleared:

const clear = Turbo.cache.clear
Turbo.cache.clear = () => {
  clear.call(Turbo.cache)
  this.broadcastChannel.postMessage({ type: 'turbo:cache-cleared' })
}

The main or modal webview can then listen for turbo:cache-cleared events and reload in the background, ensuring it's never stale. The downside is that it'll incur additional requests, so you may want to do this conditionally. e.g. I only want to reload the main webview, so I have some native code to identify main/modal webviews and deal with the cache event accordingly.

I also experimented with the visibilitychange event. After the modal has been dismissed, visibilitychange is dispatched, so this event could also be sent over the broadcast channel for handling. In this way it might be possible to reimplement the native behaviour as detailed above, but with non-full modals.

[frenkel]

Thanks! Seems like a workable solution as well.
My long term plan is to have the changes in the modal broadcast a refresh to all pages that include that content, but that'll take some time...

[dbachet]

Hi! I just started last week so I am still very far from understanding what I am doing in swift but with help of LLM I get to refresh the tabs on tap. It shows an ugly loader on white background but I think I prefer that behaviour than update something one tab 1 and data is not reflected on tab 2 and 3.

    // inside SceneController block
    private lazy var tabBarController: HotwireTabBarController = {
        let controller = HotwireTabBarController(navigatorDelegate: self)
        controller.delegate = self  // 👈 Apparently this is important!
        return controller
    }()

// extension in same file
extension SceneController: UITabBarControllerDelegate {
    func tabBarController(_ tabBarController: UITabBarController,
                          shouldSelect viewController: UIViewController) -> Bool {
        guard let hotwireTabBar = tabBarController as? HotwireTabBarController,
              let targetIndex = hotwireTabBar.viewControllers?.firstIndex(of: viewController) else {
            return true
        }
        
        let currentIndex = hotwireTabBar.selectedIndex
        
        // If we really change tab
        if targetIndex != currentIndex {
            print("📱 Change from tab #\(currentIndex) to tab #\(targetIndex)")
            
            // Fetch the URL of target tab
            let targetTab = Tab.authenticated[targetIndex]
            
            // Need to wait the tab to change before navigate
            DispatchQueue.main.async {
                print("🔄 Navigate to \(targetTab.url)")
                
                // Clear cache et navigate vers l'URL
                hotwireTabBar.activeNavigator.session.clearSnapshotCache()
                hotwireTabBar.activeNavigator.route(targetTab.url)
                
                print("✅ Tab #\(targetIndex) reloaded")
            }
        } else {
            print("📱 Re-tap on the same tab #\(currentIndex) - no reload")
        }
        
        return true
    }
}

While recording the screen I noticed that it does not show the first screen after login. I need to navigate on another tab first. 

That would be awesome to reload under the hood a selection of tabs when an event like refresh_or_redirect happens.


https://github.com/user-attachments/assets/5eea978a-cbd3-4d76-914d-264b250e6743

[dbachet]

Hi! I thought it's what refresh_or_redirect_to some_path is useful for in a controller. Indeed The update is requested to rails, then rails sends refresh_or_redirect_to some_path and it will dismiss the modal + refresh the view the modal was originating from.

Using the following:

        {
          patterns: [
            "/new*",
            "/edit*"
          ],
          properties: {
            context: "modal",
            pull_to_refresh_enabled: false,
          }
        },

Simulator.Screen.Recording.-.iPhone.17.mov

[frenkel]

Thanks! That works with a simple form like your demo indeed, but my modal contains a show page with inline edit. This means I can redirect after the inline edit is submitted, I have to show the updated page in the modal.

[dbachet]

oh alright! 👍