Implement SSR behaviour #82
Conversation
To facilitate the creation of alternative SSR behaviours, the the implementation-specific code is relocated into its own module. This is backwards compatible, but will emit a deprecation warning. There are also some basic tests to verify that we default to NodeJS for backwards compatibility.
lib/ssr/node_js.ex
Outdated
| try do | ||
| NodeJS.call!({"server", "render"}, [name, props, slots]) | ||
| catch | ||
| :exit, {:noproc, _} -> raise LiveSvelte.SSR.NodeNotConfigured |
There was a problem hiding this comment.
I didn't want to change too much, but it might make sense to have a more general-purpose SSRNotConfigured exception.
There was a problem hiding this comment.
Feel free to add this, makes sense!
There was a problem hiding this comment.
Using config here reveals the limitation that the Elixir documentation for library developers describes. What if a developer wants to use more than one SSR implementation? Or a situation where a developer wants to pull in dependencies that have different SSR implementations.
On one hand, using config is easy and it addresses the most common use cases. On the other hand, we could use macros to provide this configuration and the developer could configure the SSR module they want to use as part of their code. Macros are of course seen as unwieldy and magical, so that's the trade off.
There was a problem hiding this comment.
I think one SSR implementation is good enough. It can always be supported later if there's a need for it
|
Thank you for the great work! What still is missing is automatic setup for when you run |
|
Sounds good, I'll work on that today. |
|
@woutdp can you look over the changes? I'm getting close to finishing up a first attempt at trying creating an alternative Node JS implementation and these changes would be useful for testing. |
|
@voughtdq done, thank you for the great work! |
To facilitate the creation of alternative SSR behaviours, the the implementation-specific code is relocated into its own module. This is backwards compatible, but will emit a deprecation warning. There are also some basic tests to verify that we default to NodeJS for backwards compatibility.
I've also started working on a subproject to do end-to-end testing, but would like to iron out any concerns here before moving on to that.
Partially addresses what was discussed in #81