Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
40 of 40

Allow stripes-core's menu items to point elsewhere than module route

Done

Description

At present, the links to applications that stripes-core generates in the top menu bar are taken from those module's route property as specified in their `package.json`. This means that applications always start from their route – if you like, their route and root are the same. (This joke works much better with the British pronunciation of "route".)

But in order to resolve STRIPES-144 (interplay between UI URL and state) we need to be able to start modules at somewhere other than their route – specifically, for the UI module, at /users?filterActive=true. We'll need to modify stripes-core, and maybe stripes-loader, to support a new home property.

Environment

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Details

Assignee

Reporter

Labels

Priority

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created January 20, 2017 at 3:24 PM
Updated February 21, 2017 at 9:39 PM
Resolved January 20, 2017 at 4:10 PM

Activity

Show:

Mike TaylorJanuary 23, 2017 at 11:11 PM

Remember we have two filter (presently): show active and show inactive; either or both may be enabled – Or indeed neither. So the states are:

Now you want to invert the sense of filterActive, so that http://localhost:3000/users can be the home URL. But you don't want to invert the sense of filterInctive, because we don't want that to be on by default. So our four states are as follows (in the same order as before):

That third URL is surely a recipe of total confusion. Let's no go that route. Honesty in URLs.

Jason SkomorowskiJanuary 23, 2017 at 10:59 PM
Edited

/users?showInactive=true ...I dunno, that seems fairly sensible to me?

Is it your intent that if it COULD be read from the URL it ought always be present there? And so the default users page will be something like: /users?query=&&sortBy=surname&&perPage=20&&filterActive=true&&staffOnly=false&&probablyMore=many

Mike TaylorJanuary 23, 2017 at 10:11 PM

Consider whether or not to set the filter that lets you see "active" users. If that is on by default (which it is) but the URL does not indicate that, then there no way to see a URL change when it is turned off. You be reduced to introducing negative-sense URL parameters such as /users?doNotFilterOnActive=true. No-one wants that. Much better just to say the URL expresses the state, and that's an end of it.

Jason SkomorowskiJanuary 23, 2017 at 9:50 PM

I think it is honest (and a common idiom) for unspecified parameters to fall back to defaults. Especially in URLs!

While I'd prefer we avoid doing this, if we must, I would prefer we did so in the module's routing via a redirect rather than be introducing an additional configuration key.

Mike TaylorJanuary 23, 2017 at 1:59 PM

Well, the alternative is to have the URL lie about the state. Then when you change the state, what do you want to happen? What if there is a default filter state and a default sort state, and you change one of them in the UI: do you want the URL to reflect the changed one but have the other default to its unspecified state?

Better to be honest.

TestRail: Cases
TestRail: Runs