Mercure preventing graceful reload of Octane / EventSource best-practice
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 11.3k
- Forks
- 488
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 11
Description
Hi there! I just upgraded my Laravel Octane app to use FrankenPHP 1.3.1. Since the update I've been tinkering with Mercure, this is my first time trying it but it's looking pretty great so far 🙌
I have a couple of questions which I couldn't figure out from the docs. I'm not sure if I'm doing something wrong, or this is behaving as expected.
- Mercure preventing graceful reload of Octane?
- Whenever I change backend Laravel code, Octane detects the change and reloads the FrankenPHP worker (as expected).
- But since I've updated my frontend code to establish a connection to the Mercure
EventSource, reloads appear to hang/freeze, until I refresh the webpage connected to theEventSourcein my browser. - The moment I refresh, Octane carries on like nothing happened.
- I'm not sure if this is an issue with Octane or my setup, or if it's expected. If it's expected, how does this work during deployment reloads?
- Subscribing to multiple topics independently (unrelated to Octane, but I couldn't find a clear answer...)
- My app's frontend is built with React, and I want to subscribe to multiple topics depending which components are visible on the page.
- Because these components are loaded dynamically, I'm currently just setting up a new
EventSourcefor each component which needs to listen to a topic. - When a component unmounts,
useEffectcallseventSource.close()to tidy up the connection - This approach seems quite inefficient... If 5 components need to subscribe, 5 separate network requests appear in devtools. I figure this will add significant overhead if running at scale.
I assume I need to change my setup so there's some global/shared EventSource. Any components mounting/unmounting will need to call eventSource.close() on the global source, update the global list of topics, then re-subscribe the global source to the new list.
This... also seems inefficient? But I might be going about it completely wrong. Never mind the fact React makes shared state as hard as possible 🙃
Thanks for any pointers, it's much appreciated :)
Build Type
Official static build
Worker Mode
Yes
Operating System
macOS
CPU Architecture
Apple Silicon
PHP configuration
N/A
Relevant log output
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the Octane worker reload with a browser connected to Mercure EventSource, then compare that behavior with the React components' separate EventSource connections and useEffect cleanup. The issue names no source files or tests. Done would require a maintainer-supported explanation of the expected reload behavior and recommended multi-topic subscription pattern, potentially reflected in the documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, php, react
- Domain
- backend, frontend
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100