This episode we’re going to be talking about adding and removing parameters from your URLs dynamically, so if you’re building something like search where you have the ability to maybe search customers within a date range or add in filters for paid customers within a date range, you end up having to combine all of these hatches or these keys into a hash of parameters and those go in your URL. We need to be able to create links to add a parameter without modifying or removing the existing stuff or to maybe remove one or override one but include everything else.
That’s what we’re going to talk about in this episode: link parameters are very important for anything related to search, index pages and filtering. You might have a link to like all your customers and then you might have a link to paid customers where it sets paid is true in the URL, but then you might want to have customers within the date range and then paid customers within a date range and so this date range might be two fields you would fill out and then put dates in the URL. So you might have ?start=2018&end=2019 and maybe you are just searching by years for your date ranges, but when you click on these you want it to persist that in the URL and your links and so what we normally do is we use path helpers, but it doesn’t really work if we have dynamic stuff (for example we have to write <%= link_to "Customers Date Range", root_path(start: params[:start], end: params[:end]) %>). It’s gonna be hard coded so that we have to know these parameters ahead of time and we have to pay very very much attention to this stuff.
One cool thing is that with rails you can actually pass a hash like this <%= link_to "Customers Date Range", {start: params[:start], end: params[:end]}%> and use that as an option instead of a URL path which is cool so this is going to use the current URL and add these as parameters were set them as the only parameters on the current URL, but rewriting the URL from scratch (so it could link to http://localhost:3000/?end=2019&start=2018). We have to explicitly set every one of these options that we want and that’s going to be somewhat problematic.
You might think well wouldn’t it be nice to just have something like <%= link_to "Customers Date Range", {start: params[:start], end: params[:end]}%> , so we can take all of these params out of the URL and just put them right into our link? Well, you would be smart thinking that. However rails is no longer going to allow you to do that and the reason for that is because of strong parameters and so strong params is going to tell you that you have to permit those parameters explicitly. It’s basically doing the same stuff as we just did there but you have to use strong params and so that’s not super helpful but Rack actually provides us request.params which is what we can use for this so now we can refresh our page. End and start will still be in different orders which is fine, because rails is rewriting that URL for us, but now we can add any of these parameters in here that we would want and it will keep those in the URL as we go. We can do something like <%= link_to "Customers Date Range", request.params.except(:paid) %> if we want to say to don’t accept the paid attribute. If we try to put paid in our URL, the link you are going to see won’t include paid. This way is a great way to say: well we’ll take all the parameters in the URL except for paid users. If we have a link “paid customers within a date range”, we could do the same thing but we would have paid set to true, we’ll have something like <%= link_to "Customers Date Range", request.params.merge(paid: true) %>. You can take a look to the link and you’ll see that we get paid=true in the URL and so that way we can click these now and it will continue to persist the start and end which we’ve never specified in our code, so we can add new filters in and all of our links will continue to work as we would expect them to, which is really good. When you have search, you’re going to have lots of different parameters and different types of filters that you’re going to be passing in and so you want to do something like this with request.params so that you can merge and remove items very easily from that when you’re clicking on these different types of links. So that is how you can use request.params to add and remove parameters and persist them dynamically across links in your app, which become very very useful when you’re building search.
So that’s it for this episode I just wanted to show you a little use case of request.params in Rails and why you can’t do that with the strong params, regular thing that you use in the controllers, because it wants you to persist where explicitly state which ones are allowed. So that’s it for this little pro tip episode of Go Rails if you want to see more like these in the future, let me know in the comments below with which methods or pieces of functionality in Ruby on Rails that you would like to see and we will cover those in the future.