May you add support of querystring?
See original GitHub issueHello. May you add support of querystring in route url? I mean something like this: example.com/search?critter=bunny&gender=female&temperament=rabid&size=large&color=red
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (7 by maintainers)
Top Results From Across the Web
May you add support of querystring? · Issue #34 · tighten/ziggy
It's very possible with the current syntax although it (obviously) wouldn't work with the array syntax that's currently open in a pull request....
Read more >What Are Query Strings & Parameters - How to Optimize
Query strings are generated through a search within a webpage, form submission, or typing a query into the browser's address bar. You can...
Read more >How to Use Query Strings and Parameters for Marketers
This is a guide on query strings and parameters for marketers. Learn how to use text in a URL (query strings) for UTM...
Read more >javascript - How can I add or update a query string parameter?
I wrote the following function which accomplishes what I want to achieve: function updateQueryStringParameter(uri, key, value) { var re = new RegExp("([?
Read more >Query string - Wikipedia
A query string is a part of a uniform resource locator (URL) that assigns values to specified parameters. A query string commonly includes...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Done and Done!
Okay I’m still not 100% sure.
My two favorite options so far are
route('events.venues.show', [event, venue, queryStringParams])androute('events.venues.show', [event, venue], queryStringParams)I think your first version is fine but it is a breaking change and starts to add complexity for the most basic use-case. Basically I don’t want people who are just picking up the project to have a more complicated road to using the it.
I think the option I’m leaning to now is making
route()just return anew Router(), overriding theRouter.prototype.toStringwith all the stuff we currently have, and adding aRouter.prototype.withParamsor something (naming of this function is still up in the air) so we can chain params onto the existing router.That way someone can do
route('posts.show', 1).withParams({color: red})Here’s a quick fiddle so you can see it in action.
I think this is the most Laravel way to do it. I want to abstract unnecessary complexity out into fluency so that it’s hidden if you don’t need it. Rather than making the base function super complex with tons of additional params, lets just add fluency. It sets a good pattern for the future as well when the next hot idea for a feature emerges. Otherwise 2 months from now we’ll be scratching our heads trying to figure out how we’re going to get more data into those 3 arguments.