More flexible server fn macro api

[ealmloff]

This PR refactors the server function macro implementation into a struct that can be parsed and converted to tokens. The struct has more modular methods for derived values like the protocol based on the default configuration and the parsed arguments. This should make it both easier to maintain in the long run and easier to modify for Dioxus. I did make some fields of the server function arguments and body public to make them easier to read and modify externally. This introduces some additional semvar requirements. I have marked the newly public structs as non exhaustive so we can add fields in minor releases. Let me know if you would rather expose getters and setters or if the API surface is too broad

There are two small potentially breaking changes in this PR:

1. Some arguments like prefix now only accept StrLit instead of any Literal. This makes parsing the contents easier since we don't need to rely on the display implementation and strip the quotes manually.
2. The hashing logic is slightly different: instead of hashing the file, column, and row. This PR hashes the module path and function name. It should still be unique as enforced by the compiler, but it is slightly more stable

[benwis]

Nice work on the changes, I can see how this can become even more flexible. I'll have to see what changes are made to defining codecs so that we can bring leptos-use and the codee crate it uses along for the ride.

I have no problem with changing the generated API routes or restricting to StrLiteral, unless someone is doing something truly cursed or relying on API routes which we don't guarantee it should be good to go

[maccesch]

@benwis At the moment codee codecs are only used in Resources but not server functions. They implement their own with constructing a Request/Response directly.

Are you suggesting to use codee codecs here as well? It could be done rather easily and I'd be happy to submit a PR.

[benwis]

@benwis At the moment codee codecs are only used in Resources but not server functions. They implement their own with constructing a Request/Response directly.

Are you suggesting to use codee codecs here as well? It could be done rather easily and I'd be happy to submit a PR.

I was perhaps under the mistaken impression that codee codecs applied to server fns, since most of the obvious use cases for Resources for me involve using Resources with them. But overall yes, I can't see a reason why people wouldn't use codee codecs in this way. Especially now that we seem to be uncoupling input and output encodings and making some other changes.

@ealmloff Does this or could this also support selection of input and output HTTP verbs? I know we now have a protocol selector, so I think it's worth investigating that and differing protocols on the input/output side

[maccesch]

If I understand this correctly then codee could be used to convert from/to strings which is kind of orthogonal to the rest of the request/response in terms of verbs and headers. This would still be handled directly by the server function crate.

[ealmloff]

@ealmloff Does this or could this also support selection of input and output HTTP verbs? I know we now have a protocol selector, so I think it's worth investigating that and differing protocols on the input/output side

Yes, the protocol API added in #3656 controls the request and response together but you can still use #[server(input = ..., output = ...)] to set the input and output verbs and encodings for http requests separately. For example, it could expand to Http<PostUrl, Json> which uses the protocol Http where the input is encoded as a url encoded post request and the output is encoded as json. There are separate structs for the serialization and http request conversion functions now: JsonEncoding handles converting a type to and from bytes, and Json converts a struct to or from a Json Post request where the body is encoded with JsonEncoding

[benwis]

@ealmloff I think this is ready for merging, are you happy with it?

[ealmloff]

@ealmloff I think this is ready for merging, are you happy with it?

Yes, this will make the dioxus server fn macro much easier to maintain