The toast is customizable, it is stored in your project code in core_components.ex – look for def flash and def flash_group in that file to see how it is implemented.
You can change how it looks, and how it behaves.
There’s a thread here on this forum where we’re discussing how to delay this “trying to reconnect” message to possibly avoid it quickly flashing in and out during a redeploy or when a tab wakes up from sleep.
I recall now the main point of this thread, and so wanted to add that while Phoenix and LiveView can fit such an environment, you may get into a position in which some useful things become harder to use.
I understand by “micro-frontends architecture” you mean different parts of a single user-facing webpage is composed of multiple frontend projects, possibly using different stacks, and not relying on iframes but rather sharing a single DOM. Is that what you mean?
In that case, unless Phoenix is driving the outer shell of the app, a few things off the top of my head become harder to integrate:
- Consistent notifications such as those flash messages
- Presence and PubSub
- Backend controlled SPA-like navigation
- Possibly more
That, plus the complexity of managing the multiple frontend projects, but then you probably have some other driving factors for opting into that architecture?
In any case, happy to help!
PS: another piece of knowledge that might be super useful is understanding your options regarding state management (client side and server side). Here’s an excellent post by José Valim, Elixir’s creator: Web apps have client and server state (plus realtime and LiveView) - Dashbit Blog
