Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding more customization to NetworkLoggerPlugin. #1894
The issue we had was that response's body was only logged if we were in verbose mode. This means that if a request returns with an error, the error's body wasn't logged if not in verbose. It's ok if you don't want it, but it can be necessary according to your workflow. So we had to provide an option so that responses' bodies are logged in errors.
So I came with the following idea: list all the components that can be logged in requests & responses, and allow the user to opt-in for each one.
And to handle the issue we were facing with bodies in errors, there are 2 sets of options for responses: the
Additionnaly, I've moved all of the plugin's config into a....
So it's just a draft of the direction I want to go, It's not even tested and things may be broken atm.
Proselint report on docs/Plugins.md
Mdspell report on docs/Plugins.md:
Mdspell report on docs/MigrationGuides/migration_13_to_14.md:
@@ Coverage Diff @@ ## development #1894 +/- ## =============================================== + Coverage 92.27% 92.48% +0.21% =============================================== Files 26 26 Lines 919 932 +13 =============================================== + Hits 848 862 +14 + Misses 71 70 -1
sunshinejr left a comment
Hey @amaurydavid, thanks for doing this! And sorry for the late review. This is a really big change to the plugin and I wanted to take my time and think in what direction I would like to go with that.
And this is a very good start! I really like that we extracted all the options to a separate entity and that we are able to customize a lot more things. Additionally, as our Vision.md states:
I think we are doing a very good job on the flexibility of the API, but we need to improve on the common use cases. E.g. when I would like to print everything, now instead of just using
let provider = MoyaProvider<MultiTarget>(plugins: [NetworkLoggerPlugin(configuration: .init(requestLoggingOptions: .verbose, successResponseLoggingOptions: .verbose, errorResponseLoggingOptions: .verbose))])
which, I think we can agree, is not ideal. I know that this allows us for a lot better and more flexible logging options, but the popular use case suffers. Maybe we could try to use enum for the logging option and include what we had before + a custom one? E.g.
But I think in that case we would need to move
Let me know what do you think about it!
I agree, the necessity of having to use .verbose on all 3 parameters struck me when updating the tests.