While not answering directly to your question:

I’d say that should be a default way to go. Moreover - that gen_statem would want to live under a different supervisor and be registered under a name that LiveView process for a connection can uniquely identify (for example some user_id).. The reason is - LiveView process might get restarted because of faulty internet connection of a client.. and you don’t want to lose the state of the gen_statem, do you?

The number of processes used is still O(n) where n is the number of active LiveView connections.. (how many concurrent LiveView connections you expect to have simultaneously? 1k? 10k? BEAM by default allows upto 1m processes )

And thinking of optimizing the number of processes in such case seems like a premature optimization.

Usually it becomes a concern when the logic might dynamically spawn unbound number of processes for some computation.. for example, if you want to implement some sort of a BFS.. and even then there are mechanisms to workaround - such as using process pools which would limit the number of processes used per computation.

Follow up for others that run across this.

FSM for stateless or very thin-stated things like presentation concerns (as @RudManusachi was talking about), Saša Jurić created a now archived/non-maintained fsm library. His conclusion:

Pure functional FSMs are still my preferred approach (as opposed to gen_statem), but you don’t need this library for that. Regular data structures, such as maps or structs, with pattern matching in multiclauses will serve you just fine.

This is completely compatible with GenServer/LiveView since it’s a process-less approach.

In conclusion, using FSM inside of some process-based thing (GenServer, LiveView, etc) is achievable with Elixir primitives. Not knowing how is a basic skill issue that doesn’t necessarily need to be solved with a library or involved Erlang module.