Explicitly take path instead of location for match

[taion]

I updated the docs here, but not CHANGES because we need to comprehensively update them ahead of an interim release.

• API docs on this were out of date.
• It's almost never useful to try to call createLocation yourself to make a location object; it's almost always less buggy and easier to just pass in the path.
• This is forward-compatible with e.g. updating the history.createLocation API to take a location descriptor (rather than a list of args). (but I don't think there's a good reason to encourage users to pass in a location descriptor here)

[taion]

This is just thrown in; that function is definitely not pure async.

[taion]

Gah this is probably going to have some (trivial) merge conflicts with #2674. Please merge that PR first if we want to go ahead with making an interim release for just updating history API usage.

[taion]

My confidence that this is correct is down to 75% or so.

Looking at that API, and especially with the test case I have, it can take a location descriptor, so there's not necessarily a reason to change it (although we'd still need to call history.createLocation or at least parsePath to convert a path string into a location descriptor object).

But I don't think there's any reason to pass anything other than a path string into match.

I'd be okay either way as long as we kept the fixes to the docs for match in API.md.

[timdorr]

Looks like we're getting around to router's part of #2186 😄 (now that history has done its part)

This could start getting out of hand with changing up matchRoutes to accept LDs and strings (it just accepts LDs/locations right now).

We don't have any sort of parsePath locally, which is why I was wondering why we're getting rid of createLocation in history. It makes implementing #2186 relatively easy on router's side. Also, we don't have to worry about divergent implementations of the same functionality. It would seem to me that makes this PR a lot more clear if it continues to exist as a history API.

[taion]

matchRoutes should only accept a location object IMO - I don't think we should have any APIs that are "location or location descriptor"... I think.

[taion]

What do we think? Is there any reason to accept anything other than a path string for match?

[timdorr]

Yes, for state. It's currently being done by users, so we need to support both strings and descriptors for this API.

[taion]

Fair enough. Closing this for now, then.