You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the LemmyClient trait is implemented for both the awc client and a placeholder Fetch struct which uses gloo-net. I take it that the point of the browser client is to be able to make requests from the browser when needed. However, with Leptos's server function feature, I question if this is necessary: browser-side calls of server functions use a stub that uses the browser's native fetch API. With this in mind, is there a reason to keep this logic? Stripping it would make the client implementation much simpler.
The text was updated successfully, but these errors were encountered:
proxying everything, as we currently are, through the UI server is not a pattern i have seen before and is only nice in Leptos because of SSR and ActionForms.
it is common to progressively enhance to the browser communicating directly with the server instance as soon as it's possible to take load off the UI server
proxying everything, as we currently are, through the UI server is not a pattern i have seen before and is only nice in Leptos because of SSR and ActionForms.
You are right. Proxying through the UI server is an unnecessary step that will make things needlessly complicated.
Currently, the
LemmyClient
trait is implemented for both theawc
client and a placeholderFetch
struct which usesgloo-net
. I take it that the point of the browser client is to be able to make requests from the browser when needed. However, with Leptos's server function feature, I question if this is necessary: browser-side calls of server functions use a stub that uses the browser's nativefetch
API. With this in mind, is there a reason to keep this logic? Stripping it would make the client implementation much simpler.The text was updated successfully, but these errors were encountered: