Make it easier to use fallback extractors.
Can I have a try?
@danloh Sure. But for what it's worth, I'd no longer consider this a "good first issue".
I had a go yesterday and was getting stuck because of lifetimes and effecively needing two copies of the payload. It's more nuanced that it seems because we'd need to account for errors during body parsing and then start again parsing the fallback extractor from the beginning of the body if it failed.
OK, Thanks.
maybe I underrated it. anyway, if i fail to handle, will get back to you. ^_^
@robjtede
I really had a try but no PR yet and a gist instead:
https://gist.github.com/danloh/5290acf6f4cb073cb455d6ce0dc1af7e
get stuck on the lifetime issue or cannot meet the expected behaviour.
Thanks for your time if you are going to have a look.
I've got it working by .take()ing the payload and circumventing the lifetime issue by doing so
effecively needing two copies of the payload
My solution probably has the same issue (I'm not completely sure how .take() works internally)
Anyway, here's the gist:
https://gist.github.com/smallglitch/1f7bff2d1c9649139b362b8bf19979e1
@smallglitch take works pretty similarly to Option::take.
Having tried hard to prevent it, I think it's okay to take the payload. In particular, I'd like this feature to be tolerant to body parse failures. Eg: Either<Json<T>, String> will be able to return the whole String body when invalid JSON is sent. I'm not sure your implementation solves this use case yet though it's definitely a step in the right direction.
We could concede some performance with this feature and buffer the response into a Bytes, creating ad-hoc payloads for each extractor which would allow the fallback to have full access to the payload even in a parse failure. I think this sacrifice would be okay as long as it is documented properly.
I believe a typed future would be better than a box.
Collect an extra copy of bytes would be a great idea not only for an Either type but also useful for extract multiple types that consume the payload.