Split up `MockServer` `reply` method into static and dynamic version about http-mock-adapter HOT 11 CLOSED

@LukaGiorgadze Hi, I opened up #157 with two adjustments. I think it could be nice to even go a step further and deprecate the reply method in favor of dedicated methods for each response type. It's straight forward for callbacks and async callbacks I guess, but for static JSON responses we could think about introducing a new sealed class like this here: dart-lang/language#83 (comment)

This would allow full typesafety for all cases of response variants. What do you think?

from http-mock-adapter.

@LukaGiorgadze Okay, I will try another PR separately with the Json sealed class approach then.

For #157 I adjusted the unit tests (had to await the statusHandler call because it's now a future for all cases), added two new cases (one for each new method), and regrouped the existing tests for the request handler. Do those changes make sense for you?

I saw that collection was just upgraded to 1.18.0 a couple of days ago, so I had to manually pin the version on my test repo in order to use it. I'm currently using Flutter 3.10.5 and will soon upgrade to latest. I was creating the issue with http-mock-adapter v0.4.4 and built the PR with v0.5.0.

Btw, what's up with the matcher section of the project? How can I make use of it? I would also like to add some documentation for new users of the project as I think the project is awesome and can help a lot of people.

from http-mock-adapter.

#157 has been merged

from http-mock-adapter.

Thanks @sebastianbuechler makes sense, currently I don't have to make this change, unfortunately, but you can make PR and I'll approve. Or I can address this in the future.

from http-mock-adapter.

Hi @sebastianbuechler, your proposal makes sense, I agree with that. Thank you!
Just make sure tests are passed since they are failing https://github.com/lomsa-dev/http-mock-adapter/actions/runs/5923116833/job/16058693248?pr=157

And will merge this.

I upgraded dependencies and upgraded the collection to 1.18.0 but since the stable version of Flutter still depends on an older version of the collection, I'll first downgrade the collection package and then release your changes with a major version since it might be a breaking change for some people.

btw, what version of Flutter and http-mock-adapter do you use?

from http-mock-adapter.

@sebastianbuechler Thank you Sebastian, updating the document makes really sense.
I'm thinking to downgrade the collection back, my gut feeling tells me Flutter stable is far away from upgrading the collection, so does it make sense to keep 1.18? I'm curious how it works for you.

from http-mock-adapter.

@LukaGiorgadze I have the same feeling that it still will take some time until will be useful. I don't see currently a reason to not downgrade, to be honest.

from http-mock-adapter.

@LukaGiorgadze I have the same feeling that it still will take some time until will be useful. I don't see currently a reason to not downgrade, to be honest

@sebastianbuechler Look at this #155
Did you face the same issue?

from http-mock-adapter.

@sebastianbuechler btw, I've invited you as a collaborator with write access.

from http-mock-adapter.

@LukaGiorgadze I have the same feeling that it still will take some time until will be useful. I don't see currently a reason to not downgrade, to be honest

@sebastianbuechler Look at this #155 Did you face the same issue?

Yes, exactly. I just set an override in my pubspec.yaml:

dependency_overrides:
  collection: ^1.17.1 # Temporary fix for http_mock_adapter

from http-mock-adapter.

@sebastianbuechler btw, I've invited you as a collaborator with write access.

Thanks you!

from http-mock-adapter.