Added uri construction for queryParameters

[Lorenzohidalgo]

This PR intends to help avoid replicating code when using the beamer package and URI's with query parameters. While refactoring my code I came across multiple navigation calls where I could avoid manually constructing the URI if the beamer package accepted query parameters as an input.

I've made the following changes:

• added Map<String, dynamic>? queryParameters as an optional input parameter for: beamToNamed, beamToReplacementNamed and popToNamed
• added the private function String constructUri(String uri, Map<String, dynamic>? queryParameters) that return the URI with the formatted query parameters appended at the end.
• added unit tests for the new function.

@slovnicki feel free to request any additional changes to my code or discard the pull request if you don't consider the changes relevant/useful.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.91%. Comparing base (1aa33d3) to head (738b002).
⚠️ Report is 74 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #563      +/-   ##
==========================================
+ Coverage   96.62%   96.91%   +0.29%     
==========================================
  Files          13       13              
  Lines         888      909      +21     
==========================================
+ Hits          858      881      +23     
+ Misses         30       28       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[slovnicki]

@Lorenzohidalgo Thanks for the PR! 💙

This is definitely a useful feature, but now that I think of it... Maybe we should switch to Uri altogether instead of String for named beaming 🤔 Sure, this will be a breaking change, but this is expected for the v2 we're working on. Let me know what you think about that. The only thing that concerns me is that it is a significant breaking change and a bit of a hassle for apps that really use only path. I wish we could take the best of both worlds without over-complicating the API.

We should also update all the functions in BeamerDelegate to make use of this new feature, be it your constructUri helper or complete switch to Uri. And if we stay with the constructUri option, maybe a better place for it would be utils.dart.

[Lorenzohidalgo]

Hi @slovnicki, Thanks for your feedback! I also agree that maybe switching to Uri altogether would resolve the issue, but as you mentioned it would be a breaking change and more complex/cumbersome for users with more straightforward implementations. To avoid creating a breaking change or making it more complicated for other users I went with the constructUri approach.

Either way, I would be happy to help with implementing this further. Just let me know If I should make the complete change to Uri or just continue updating the functions to use constructUri as mentioned in your last paragraph.

[slovnicki]

@Lorenzohidalgo Yeah, it might be best if we don't do the full transition to Uri yet. Let's complete your constructUri proposal and maybe we can discuss the transition to Uri after, in some other PR.

[Lorenzohidalgo]

Perfect @slovnicki , I'll implement the requested changes and let you know once it's ready for the next review 😉

[Lorenzohidalgo]

Hey there @slovnicki ,

I've finally had a moment to fix the requested changes:

We should also update all the functions in BeamerDelegate to make use of this new feature, be it your constructUri helper or complete switch to Uri. And if we stay with the constructUri option, maybe a better place for it would be utils.dart.

Let me know if anything else should be updated 😉