Add BrowserHistory and BrowserLocation

[futursolo]

The PR adds an initial BrowserHistory and BrowserLocation implementation that was implemented for yew-router.

Comparing to yew-router's implementation, it strips the following features:

• typed routes.
• base name handling.

History leaking

(a.k.a: sometimes it's possible to cause the page to reload, or navigate away from the SPA with certain methods like history.go(0))

After some consideration, I think it ultimately does not matter too much and is kind of hard to prevent.

• history.go(0) is equivalent to location.reload().
  Which means the user should know what they are doing when they are calling this method with 0.
• history.back() or history.go(-1) (or history.forward() and history.go(1))
  If the last state is created by history.pushState, then a popstate event will be fired.
  If the last state is on another page, then user will be navigated back to the last page.
  If this is the first state in the history queue, then nothing happens.
  In addition, there's no way to "peek" the next history which means we cannot really know what would happen unless it really happens.

JavaScript version of history does not patch / trying to prevent this either:

https://github.com/remix-run/history/blob/main/packages/history/index.ts#L521

[ranile]

Looks fine for the most part. I've left a few comments (some of them apply everywhere but I've noted them at one place)

[ranile]

Why modify timers here? Let's do it in a separate PR

[futursolo]

This is purely to make CI happy or else CI wouldn't pass.

https://github.com/rustwasm/gloo/runs/4295589107?check_suite_focus=true

[ranile]

Looks good for the most part, just a few comments

[ranile]

I forgot to add this in the previous review...

[ranile]

Only the references to serde feature which was renamed stuck out to me. Other than that, this looks good to me

[ranile]

I saw your messages on the Yew discord advising against directly calling it. Should this be pub(crate) function instead of Default implementation? That way, it won't be part of the public API

[futursolo]

I didn’t recommend it due to it is not a good practice inside components and users should use hooks instead. Not that default implementation itself has any issue.

I think an updated implementation will no longer expose History interface via hooks, so I am fine with default implementation.

In addition, it trips up clippy if you have a new method, but no default implementation.

[ranile]

LGTM.

I'm going to go ahead and merge this so it's not a blocking factor for more history-related work in both Gloo and Yew. Should anything needs to be patched up, it can be done in another PR