Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
First attempt at basic axum-style state management
Empty service/handler impl I'm starting to understand the basis of Tower's service model. However, that does not make this attempt good. This only covers the case of a function that takes no arguments (and that is on purpose). In order to take more arguments, I will need to create a trait which can handle them, think something like Axum's `FromRequest`. We will need an adapted form of this, since we actually will want it for `FromEvent`. You might be wondering why we don't just use `From<Event>`, but that is annoyingly problematic, since you will get conflicting implementations because "downstream crates may implement this for ..."; as far as I can tell, this will require a custom trait. I have not yet found a way around this. Add Handler impl for up to 3 args Ah ha! I found the secret! So it's true that you can not just take in any argument for the first one. That's essentially special-cased. But, assuming that most functions' first argument would be the event itself (atspi::Event = Request), then we can make that the first argument, followed by N arguments that implement `From<State>` (roughly). This will allow us to implement `From<State>` for various types, which will be wrappers of more widely available types, for example: - Current/LastFocusedItem(CacheItem) - Current/LastCursorPos(CacheItem, u32) - EventItem(CacheItem) - etc. Add generic first parameter for Handler This allows the first parameter to be any type that implements `TryFrom<atspi::Event>`. It currently requires an unwrap due the possibility of it being the wrong event type. This should be converted into its own Layer type, which can easily wrap the inner service, instead of manually implementing the conversion within the `Service` impl for `Handler<_>` types. Add a quick breakdown, in English, of the trait bounds of a Handler impl formatting
- Loading branch information