Delay transition on a higher level

Hello, I am trying to improve something I build which lets you delay a route transition for a certain time. This can be useful if you want to show and animated loading ui before the actual transition start.

In the application route you can use the willTransition action to do something dodgy. To delay a transition can cancel it and execute a timer (I use ember-concurrency for added benefits) and once it finished you can retry the transition. There are a few complications but nothing to crazy to solve. The problem I have with this, is the approach, as there are a few side effects like the router-service events now been spammed with the aborted requests just to mention one issue.

So my question is, is there a nicer way to do such a thing? Should I temper with the router services transitionTo method (reopen)? Generally this is bad practice and I am not a big fan.

What I dont want to do is to wrap every ‘transitionTo’ call in a later call.

Cheers Thomas

I played around with this which works but a colleague thinks that renderTemplate is going away with octane, and I am kind of back to where I started.

within an initializer.

    deactivate() {
      const timer = this._timer
      if (timer) cancel(timer)

    renderTemplate(_controller, _model) {
      set(this, '_timer', null)
      const timer = later(this, () => this.render(), TIMEOUT)
      set(this, '_timer', timer)

The simple solution would be - wrap every transitionTo call with a later call, but thats just a little excessive within our app (util usage would make it better but its still a new api everyone needs to know). I tried modifying the routers transitionTo method but I was not able to do so :frowning: .

I thought about artificially lengthen route model hooks, as they are promise based but models are not always called when going from a child route to a parent route, so I canned that idea.

Does anyone has some other ideas.

renderTemplate isn’t going away in Ember Octane, but it is marked for deprecation long-term.

The details of this deprecation are in RFC 418, which was merged in 2019:

Given Ember’s versioning strategy, I would expect the deprecation warnings to start in Ember 3.x, and the method to be removed in Ember 4.0.