add flexibility to Post setUrl method

[mjauvin]

The blogPosts component calls each posts setUrl() method but cannot provide the currently selected category.

this PR adds a $params array to allow overriding parameters when setting the post's URL.

the PR modifies the blogPosts component by passing the current category when setting each post's url.

[LukeTowers]

Could you provide an example of behavior that this PR now enables? It doesn't quite make sense to me.

[mjauvin]

If you have blog posts that have more than one category, the post url will be built using the first category instead of the currently selected category. So if your blogPost page has the following url, the category was always the first category:

url = "/post/:slug/:category?"

Now it property assigns the selected category.

[bennothommo]

@mjauvin Looks fine to me - I'll give it a test tomorrow and merge it if it's all good.

[mjauvin]

Hi @bennothommo, did you get a chance to test it?

[bennothommo]

@mjauvin Sorry, I haven't yet. I will try to get onto it shortly.

[mjauvin]

Any luck @bennothommo?

[bennothommo]

@mjauvin I've tested it and it works, but I'm now in two minds about allowing people to override all the parameters - the category, sure, but not so much the ID and slug. What are your thoughts on just allowing the category to be overridden through the third parameter in setUrl?

[LukeTowers]

@bennothommo what are your concerns with the current approach?

[bennothommo]

@LukeTowers mainly just being able to override the other params - such as id and slug. I feel they should be locked down in some way so someone doesn't inadvertently make incorrect URLs.

[LukeTowers]

@bennothommo I feel like if they do, they're doing it on purpose. It's not like they can accidentally pass that data in, they have to be very explicit about it. I feel like it adds the greatest degree of flexibility and support for future params we may want to use without being a massive pitfall for users / developers.

[mjauvin]

Frankly, I don't personally think this is an issue but I do think adding this is supposed to help flexibility/extensibility so it IS possible to cause mayhem (as it is with many event handlers if we want to go that far)

[bennothommo]

I can't think of a specific scenario where this could cause mayhem without it being the result of someone doing something intentionally stupid, so I'll merge it. There's just one change I'll suggest first before doing so.

Completed

[LukeTowers]

LGTM, @bennothommo you can merge when you're happy with it.