Documentation on how to make custom extractors
Is your feature request related to a problem? Please describe. I want to create a custom extrators for my app.
Describe the solution you'd like Add an example of a extrator that access state.
Describe alternatives you've considered Just docs
Additional context I need to create my custom extrators but i found so far the following issues:
- When i implement
FromMessageParts(or any of these handler traits), i can't get thejson_serde::Valueandbytes::Bytestypes (you should export these), i currently usingsqlx::types::JsonValueandaxum::body::Bytes. - If i need my custom extrator to access socket state, the only solution at the moment is to create the state from the current message (also for other type handlers) i.e.
State::<T>::from_message_parts(s, v, p, ack_id)which returnsResult<Self, StateNotFound<T>>, so i have consum the result and covert to option usingok(), and finallyunwrap()the option, which is safe in my context but i think we need a better way to do this kind of extractors (axum gets the state as parameter in thefrom_request_partsfunction). - Also we need a way to multiple extrator like axums does i.e `Data((one, two, three)): Data<(TypeOne, TypeTwo, TypeThree)>
I agree that custom extractor implementations lack examples and docs.
However I'm curious about what you are trying to do, because if you want to access the axum state you simply have to make a shared state and add it to both axum and socketioxide with with_state and then you can use the State extractor provided by socketioxide.
But maybe I didn't understand your issue.
I want to access socket state not Axum state, I want to inject my database repositories in handler arguments (just I do with Axum) so I can't skip boilerplate in my socket handlers
For your first point:
I re-exported the socketioxide Value type #382 to easily implement extractor traits. It will be available in the next major version. However if you want to manually deserialize it to a specific type you need to use Data::from_{connect,message,disconnect}_parts.
For you second point: I agree that accessing the state is currently complex. The state system deserve an improvement to match the axum state system. I still want to wait before modifying this part.
For your third point:
I don't understand what you want to do? Data<(Type1, Type2, Type3)> will deserialize data to a tuple of three types according to the incoming payload.