Skip to content

Routing and Layering #551

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zoomclub opened this issue Dec 1, 2014 · 20 comments
Closed

Routing and Layering #551

zoomclub opened this issue Dec 1, 2014 · 20 comments

Comments

@zoomclub
Copy link

zoomclub commented Dec 1, 2014

Using Z layers is an important feature in modern apps and a logical addition to routing, so that all aspects of layout (nesting and layers) are covered. Is it possible to add layers to components and manage them with react-router to complete all my design dreams?

@ryanflorence
Copy link
Member

What is a "Z layer"?

@mjackson
Copy link
Member

mjackson commented Dec 1, 2014

What is a "Z layer"?

I assume @zoomclub is talking about stacked views (think z-index).

@zoomclub What kinds of things would you want the router to do for you in this regard? Help me understand some use cases.

@zoomclub
Copy link
Author

zoomclub commented Dec 1, 2014

Yes, I meant stacking views using the z-index. My own use case requires several layers:

• background canvas, where accepted edits are rendered
• foreground tool picker, engaged when pointer is detected in specific location
• foreground sheet editor, used to browse and edit various app configs/prefs
• foreground tool editor, where the main editing tools are used
• foreground reporter, transparently displays dynamic info for tool operations

These are just layers, like interactive games or modern apps often have. There is an existing react-layers project (https://github.com/pieterv/react-layers), which makes a simple feature more complex than it need be. It would be best to bring everything under the one roof of react-router. After all layering is also routing, just on the z-index.

@ryanflorence
Copy link
Member

Every child route view is going to be above the parent because when z-index is the same, the child element is "above" the parent.

How would the router help with this?

@mjackson
Copy link
Member

mjackson commented Dec 1, 2014

@zoomclub I see, thanks for elaborating. This is really interesting.

@rpflorence Think of the "nested router" stuff you were talking about a while ago, for modals. That would solve the layering problem perfectly.

@ryanflorence
Copy link
Member

but z-index doesn't matter, the child views will always be higher in the z-index "stack" because they are children, if you mount a sub-router on some top-level page, just make sure its later than the parent router's RouteHandlers in your render and it'll still be "higher".

I'll drop out of this thread for a bit, I've got some weird bias against it that I can't identify and I'll just end up killing would might be a great conversation :)

@zoomclub
Copy link
Author

zoomclub commented Dec 1, 2014

Agreed, z-index does not matter, just having Z layers does. Essentially, I'm hoping to use one robust solution for routing at the end of the day and confirm that such a robust solution exists.

So just be be clear, using react-router there can be one main route handler stacked with the layers described above. Each layer component can then also define its own sub route handler as required, which is active when a given layer out of the set of layers is activated? Layers would become activated by a pointer or qwerty trigger or automatically by some other function as desired.

As long as stacked layers in the main route handler can be switched (shown/hidden) along with the option to also have multiple layers showing we are good to go? When multiple layers are active the foremost layers could be made transparent as an option, which is not a direct react-router feature rather just an aspect of the given layer. If layered components can also be transitioned to with some fun animation I'll be content :)

If layered components are a breeze to accomplish with react-router then its a good thing to acknowledge and make note of in the documentation. Maybe a few handy layer friendly functions can be included and demonstrated?

@natew
Copy link
Contributor

natew commented Dec 2, 2014

I'm attempting to solve this issue by using contexts outside of react router. So far it's working pretty well. Basically all your route handlers should have a mixin that sets a layer, but increments the layer once mounted. It's pretty easy to implement but I've run into some problems with getting the context to pass through RouteHandler.

Could be an issue on my end, or an implementation issue with contexts, but unfortunately it's a blocker for me. Definitely a wanted feature though. Once you start building complex UI's you need to manage a whole variety of z-index edge cases that don't just let you rely on the default layering.

See #549

@zoomclub
Copy link
Author

zoomclub commented Dec 5, 2014

Using the mixin sounds pretty slick. Looks like react-router is still growing rapidly.

@cmwelsh
Copy link

cmwelsh commented Jan 17, 2015

This seems like this is a duplicate of #266.

I currently have a UI like this that I'm rendering "manually":

http://instagram.com/github

Notice how the URL changes when you click a photo from the list and the details view is rendered in a modal. However, the background stays rendered as well.

@zoomclub
Copy link
Author

The modal dialog and offcanvas approaches are both popular and represent ways of layering divs. This can work for some of what I'm going for but is not then an integrated solution for react-router.

I'm thinking more along the lines of defining react components for each class of editor used in the app. These components contain all their sub-components and react-router is the right solution for managing the layout within each of these editor class components.

Essentially, there are the bigger editor components then, with their inner sub-components that are reused and fed different state data per use case. An onboard react-router is perfect for managing the layout and morphing of the sub-components into alternate layouts within a given editor.

That part works fine. Now we want to work these component editors into layers. Maybe its just easier to create a simple var with an array of these editors and a function to hide, show, blend, send to back, bring to front the editors plus manage nice animations as the layers are transitioned?

It would be straightforward, basically having a stack of editors much like there is often a stack of canvases in drawing apps. I just thought this kind of functionality might go hand in hand with react-router? It would add a little Z dimension to what is now a flat X and Y router landscape.

@zoomclub
Copy link
Author

Apparently I Inadvertently closed this issue, that was not the intent :)

@cmwelsh
Copy link

cmwelsh commented Jan 19, 2015

You probably clicked Comment and Close instead of Comment.

@zoomclub
Copy link
Author

Thanks for letting me know, I'll reopen it for further discussion then. I came across the following demo yesterday that is related to the the kind of layering of components I'm hoping to achieve. It has its own little router, see the code here:

http://coenraets.org/blog/2014/12/animated-page-transitions-with-react-js/

@zoomclub zoomclub reopened this Jan 19, 2015
@irvinebroque
Copy link

Encountering this today, and I think exposing a way to get the "depth" of a given route would solve a lot of this, without React-Router actually managing z-index directly.

For example, let's say I have the following route config, where the New Message route is a modal:

<Route name="App" path="/" handler={App}>
  <Route name="Messages" path="messages" handler={Messages}>
    <DefaultRoute name="Overview" handler={Overview}/>
    <Route name="New Message" path="new" handler={New}/>
  </Route>
</Route>

Within the New Message component, I'd love to be able to write something like:

this.getRouteDepth()

Which would return 3, because the New Message route is nested 3 levels deep. If this.getRouteDepth() was called inside of the App component, it would return 1. These numbers could be easily mapped to any arbitrary z-index values.

Right now, here's what I do:

  // Z-Index management
  var depth;

  this.props.routerState.routes.forEach(function(route, index, array) {
    console.log(route)
    if (route.name === this.props.routeName) {
      depth = index;
    }
  }.bind(this))

  // Use depth to set z-index on the route
  styles.zIndex = depth;

This requires that I pass down a string for this.props.routeName to my view wrapper component, and this string must exactly match what comes back from the router's state object. It makes changing the names of routes brittle, because they need to be updated in two places.

@natew
Copy link
Contributor

natew commented Jan 27, 2015

If you use the RouteHandler mixin, you have a getRouteDepth function available:

https://github.com/rackt/react-router/blob/e75dbc5419ecdefbec4be9dc301303d8e7c0a3f0/modules/RouteHandlerMixin.js#L37

@mjackson
Copy link
Member

@irvinebroque awesome, you even chose the same function name as one we already have ;)

see @natew's comment! :D

@irvinebroque
Copy link

Clearly I haven't been paying close enough attention to the upcoming release, I had no idea. Well done!

@ryanflorence
Copy link
Member

With getRouteDepth, you can do z-indexing as well as decide which "layer" (I call them portals) to render to if that's what you're doing, you'll have to wrap the RouteHandler in the loving embrace of the context its going to need to work, but you could do it.

Please holler to reopen if I'm wrong :)

@zoomclub
Copy link
Author

zoomclub commented Feb 1, 2015

Its been an exciting week with react and also web audio conferences this week, much on the horizon! Glad to hear of the added layer support in react-router. Layers are practical and fun, saw this nice inspirational layer implementation last week:

http://stas-melnikov.ru/layered_responsive_modal_window/

@lock lock bot locked as resolved and limited conversation to collaborators Jan 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants