-
-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Support functions that can run on the client in ActionForm #2326
Comments
To clarify: Do you mean that you want to specify "I want this to be a server function, so that if JS/WASM is not available in the client, it runs on the server, but it actually doesn't need to run on the server, so run it in the client instead if that's possible?" I guess my main question is "why?" i.e., what's the use case? Is it a situation where you're calling out to some third-party API and could save a network call by doing it from the client and not the server (and you won't have CORS issues?) |
Yes.
I currently don't have a use case myself. I just found it conceptually strange that an ActionForm requires to run the action on the server. But I have a hypothetical use case: A search bar, where you search through a list of items that has already been loaded from the server. But if you think this feature is not important, feel free to close the issue. |
Is your feature request related to a problem? Please describe.
AFAIK, ActionForms only support actions that were created using
create_server_action()
, i.e., it only supports server functions. However, when JS/WASM is enabled, there's not always a reason why the function must run on the server.As I understand it, server functions provide two things:
But for ActionForms, it seems that we only need (1.), in order to support clients that have JS/WASM disabled. When JS/WASM is enabled, the function could run on the client. Therefore, this feature request could also be termed as:
"Support server functions that can also run on the client."
Describe the solution you'd like
This could be solved with an attribute to the #[server] annotation that allows the server function to run on the client, i.e., only the server API is generated, but it's not used in a JS/WASM-enabled context.
The text was updated successfully, but these errors were encountered: