Smarter goBack

[simenbrekken]

Currently one has to use ActiveState with a willTransitionTo hook to know if Navigation.goBack will do anything. It would be nice if goBack returned a boolean that tells you wether it there's anything in history (as managed by react-router).

[seidtgeist]

I would also be interested in this. However, I'm not sure what the right solution would be.

Think of a similar use case involving a list view and a detail view. Given a detail view can be visited directly by URL it won't have a meaningful previous history entry (instead it's the empty tab page in Chrome). Therefore, the classic history goBack behaviour will not do anything meaningful when clicked. Perhaps being able to query the managed history would make sense here: If there's no previous entry, do something else in the render method or the click callback.

[gaearon]

+1! I only use goBack for Cancel buttons but it sucks because I don't know if the user hit page directly.
Unless you use RefreshLocation, it's unlikely you ever want to send user to previous website.

[mjackson]

Seems like the primary use case here is wanting to know whether or not there's anything in the history to goBack to. Would it be enough to just have a canGoBack() method somewhere?

[rickharrison]

+1 on canGoBack. I would find that very useful.

[seidtgeist]

👍

[gaearon]

From my understanding canGoBack something router should manage, since browsers don't seem to provide reliable/same API for this.

Should canGoBack be scoped to current application? I think yes. If I came to Google and I'm on my initial route, I suggest it returns false.

Should canGoBack return true or false with RefreshLocation? That's a tricky one, and while returning false is consistent with previous point, it's not too obvious. If canGoBack was called canGoBackWithoutRefreshing it would make more sense, but the name sucks.

Ideas?

[seidtgeist]

Should canGoBack be scoped to current application? I think yes. If I came to Google and I'm on my initial route, I suggest it returns false.

Definitely. Can't think of a use case where it would make sense to go back to an external website or empty tab. That's why we need this in the first place :)

RefreshLocation

I just read up on RefreshLocation. Tough question. Is it even possible to determine whether the navigation is at the start of history when using it? I couldn't see any state tracking, but I'm not sure it's in there.

[gaearon]

I think returning false for RefreshLocation is OK.
It just says “we can't guarantee you'll stay where you are so proceed on your own risk”.

However there's yet another subtlety here. Should goBack() do anything if canGoBack() returns false?

One real-world example of this happening is when transition.abort() happens on very first route. Currently, it will kick you out of the website. If goBack() is a no-op when canGoBack() is false, it will just render blank screen. What makes more sense? (Should you even be able to abort first transition?)

[mjackson]

Maybe we do this:

• make goBack a no-op if we don't actually have any history (in the current app, ofc)
• if we don't have history and the user tries to goBack trigger a warning (so the dev has some feedback about why it didn't work)
• change the signature of goBack() to goBack(force=false) so devs can force the browser to go back when they're using RefreshLocation. Or maybe just default force=true if we're using RefreshLocation

I think that would satisfy everyone's use cases here.

[gaearon]

Sounds wise. Certainly satisfies mine.

[rickharrison]

What would the warning be. In my case if goBack can't accomplish anything, I would instead like to transitionTo another route. So essentially I need this:

if (canGoBack()) {
  goBack();
} else {
  transitionTo();
}

[gaearon]

I think goBack should return a boolean of whether action was performed.

if (!goBack()) {
  transitionTo();
}

So it's goBack(force: bool = false): bool.

[mjackson]

@gaearon ya, that sounds good.