feat(router): added vetoable preLeave event

[pavelgj]

BREAKING CHANGE

Previously, vetoing was allowed on leave (RouteLeaveEvent) which caused
issues because routes had no way to recover from other route vetoing a leave
event.

Now, similar to preEnter and enter, leave event was split into vetoable
preLeave (RoutePreLeaveEvent) and non-vetoable leave (RouteLeaveEvent).

views.configure({
  'foo': ngRoute(
      path: '/foo',
      preLeave: (RoutePreLeaveEvent e) {
        e.allowLeave(new Future.value(false));
      })
});

[vicb]

expect(root).toHaveText('');

[vicb]

LGTM. Could you please put this PR description in the commit message (as this is a BC break) ?

Some remarks / questions about route.dart:

• What about adding a CHANGELOG..md - that could ease user life
• Why not using semver ? currently there is now to discriminate when a new feature is introduced vs a BC break release - that would also ease user life

[pavelgj]

@vicb PR message is identical to commit message.
Good suggestions on changelog and semver.

[vicb]

@pavelgj you're right, I was expecting "..." on the GH UI but it's not on this PR page. Sorry for the noise.

[vicb]

Oh I thought this was already merged - do we need to wait because it breaks BC ?

[vicb]

Then I think my commit could also be considered as a BC break - the BC is broken because the route dependency was/is '>=0.4.18/21 <0.5.0' and the router does not use semver (I think this i still true for the DI also) and BC was broken in route v0.4.21.

If this should be fixed, the dependency should be "=0.4.20"

[pavelgj]

Sorry, I'm out of context, what's the problem with upgrading to 0.4.21?

[naomiblack]

I'm also out of context... what's BC you guys? Are you using this as code for "breaking change"?

Pavel, I think the issue @vicb is raising is that when he changed the pubspec.yaml file in 7c9a758 to depend on route 0.4.21, he inadvertently introduced the breaking change in route to angular.dart.

If we are following semver for angular.dart, then we should fix the dependency on route_hierarchical: '=0.4.20'until we declare the next breaking change in angular.dart and/or fix it in a backwards compatible way.

Technically, semver also says that anything 0.y.x is unstable anyhow, so this is a discussion over semantics. But since we haven't declared 0.12.0 yet, I think the most consistent thing to do is either to change pubspec.yaml to route_hierarchical: '=0.4.20'in 0.12.0 and then fix routing in 0.13.0 by including this PR and updating to route_hierarchical: '>=0.4.21 <0.5.0, or if the two changes cancel each other out, then just making both changes in 0.12.0 and messaging appropriately in the release notes. I think we haven't yet posted 0.12.0...

[vicb]

BC stands for backward compatibily here.
The problem is not with 0.12 but with the already released 0.11 - you can break your app only by running a pub upgrade.
Pub recommends something stricter than semver only for pre 1.0 and we should stick to that to having bugging the users for no reasons.
We have already discussed that offline and agree to be stricter for next releases.