ui: ugly urls

[BramGruneir]

When checking node status, I get redirected to this url
http://104.196.56.219:8080/#/nodes/overview?_k=7kazps

The url should just be, and all options should always be human readble.
http://104.196.56.219:8080/#/nodes

This is true for all urls, there's always a k option added that shouldn't be there.
Another example the cluster page shouldn't be:
http://104.196.56.219:8080/#/cluster?_k=k1odh2
It should be
http://104.196.56.219:8080/#/cluster

[tamird]

OK but who cares?

On Tue, Jul 12, 2016 at 12:00 PM, Bram Gruneir [email protected]
wrote:

When checking node status, I get redirected to this url
http://104.196.56.219:8080/#/nodes/overview?_k=7kazps

The url should just be, and all options should always be human readble.
http://104.196.56.219:8080/#/nodes

This is true for all urls, there's always a k option added that shouldn't
be there.
Another example the cluster page shouldn't be:
http://104.196.56.219:8080/#/cluster?_k=k1odh2
It should be
http://104.196.56.219:8080/#/cluster

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7777, or mute the thread
https://github.com/notifications/unsubscribe/ABdsPFKf6-iylFCpufUjCxaNQcSZcwl4ks5qU7o5gaJpZM4JKjF0
.

[BramGruneir]

I do.
And I'm going to bet that our designers will as well.

If there was a clear need for this value it would be one thing, but it's an
option that can be turned off and should be.

On Tue, Jul 12, 2016 at 12:12 PM, Tamir Duberstein <[email protected]

wrote:

OK but who cares?

On Tue, Jul 12, 2016 at 12:00 PM, Bram Gruneir [email protected]
wrote:

When checking node status, I get redirected to this url
http://104.196.56.219:8080/#/nodes/overview?_k=7kazps

The url should just be, and all options should always be human readble.
http://104.196.56.219:8080/#/nodes

This is true for all urls, there's always a k option added that shouldn't
be there.
Another example the cluster page shouldn't be:
http://104.196.56.219:8080/#/cluster?_k=k1odh2
It should be
http://104.196.56.219:8080/#/cluster

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7777, or mute the
thread
<
https://github.com/notifications/unsubscribe/ABdsPFKf6-iylFCpufUjCxaNQcSZcwl4ks5qU7o5gaJpZM4JKjF0

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABihubECutIgbx-fj1-4C0N4ZKiLzm82ks5qU7zagaJpZM4JKjF0
.

[tamird]

If you know how to turn it off, care to mention that in the issue
description?

On Tue, Jul 12, 2016 at 12:21 PM, Bram Gruneir [email protected]
wrote:

I do.
And I'm going to bet that our designers will as well.

If there was a clear need for this value it would be one thing, but it's an
option that can be turned off and should be.

On Tue, Jul 12, 2016 at 12:12 PM, Tamir Duberstein <
[email protected]

wrote:

OK but who cares?

On Tue, Jul 12, 2016 at 12:00 PM, Bram Gruneir <[email protected]

wrote:

When checking node status, I get redirected to this url
http://104.196.56.219:8080/#/nodes/overview?_k=7kazps

The url should just be, and all options should always be human readble.
http://104.196.56.219:8080/#/nodes

This is true for all urls, there's always a k option added that
shouldn't
be there.
Another example the cluster page shouldn't be:
http://104.196.56.219:8080/#/cluster?_k=k1odh2
It should be
http://104.196.56.219:8080/#/cluster

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7777, or mute the
thread
<

https://github.com/notifications/unsubscribe/ABdsPFKf6-iylFCpufUjCxaNQcSZcwl4ks5qU7o5gaJpZM4JKjF0

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
#7777 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ABihubECutIgbx-fj1-4C0N4ZKiLzm82ks5qU7zagaJpZM4JKjF0

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABdsPG84wDAjQxYSf9YlmFny-CxDHwYZks5qU78kgaJpZM4JKjF0
.

[maxlang]

cc @mrtracy

remix-run/react-router#1967

[BramGruneir]

@tamird I didn't know that at the time. Found it after some discussion with @maxlang and I couldn't update the issue due to github errors.

[mrtracy]

I agree that this is a non-issue, but if it's trivial to take out (and doesn't have consequences) we can do it.

[BramGruneir]

Really, we should be using browserHistory instead of hashHistory.

https://github.com/reactjs/react-router/blob/6117def486a813221d0d254b0b4920afbbc51d48/docs/guides/Histories.md#browserhistory

The only reason not to is because of older browser compatibility, which isn't an issue for us.

[tbg]

Isn't older browser compatibility an issue for us?

On Wed, Jul 13, 2016 at 11:06 AM Bram Gruneir [email protected]
wrote:

Really, we should be using browserHistory instead of hashHistory.

https://github.com/reactjs/react-router/blob/6117def486a813221d0d254b0b4920afbbc51d48/docs/guides/Histories.md#browserhistory

The only reason not to is because of older browser compatibility, which
isn't an issue for us.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AE135Oj_Bg5oOs8zbM_osF9ijOShajCBks5qVP79gaJpZM4JKjF0
.

-- Tobias

[BramGruneir]

Why would it be?
Are we really worried about IE8? Or very old versions of chrome or firefox?

I think it's fair to assume that those that are using the ui have fairly up to date browsers.

And even if they don't, it only means a full reload instead of a partial page reload, so it will still be functional.

[BramGruneir]

Also, by going with browserHistory, we remove the hash from the urls.

[tbg]

I'm not familiar with the tradeoffs, just asking. I'm sure we need some
compatibility with older browsers. I don't think we've worried about it
much, though.

On Wed, Jul 13, 2016 at 11:12 AM Bram Gruneir [email protected]
wrote:

Also, by going with browserHistory, we remove the hash from the urls.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#7777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AE135IFGk23extzLBuyLouNnP1yzak3uks5qVQBdgaJpZM4JKjF0
.

-- Tobias

[maxlang]

This should be reopened since the PR was reverted.

[mrtracy]

I'm just going to close this as WontFix. We cannot support BrowserHistory without server-side support, and react-router's HashHistory appears to think the extra bit in the query string is important for reliable back-button navigation.