Top-level app component and animated route transitions about next.js HOT 135 CLOSED

What's the status of this given the recent release of v4.0.0? Is it on the roadmap to fix? Already fixed? Easier to fix? Harder to fix?

from next.js.

Literally the only feature missing in next.js.
@arunoda, is the possibility to have a top-level component on the road map ?
Thought it would be implemented in v4

from next.js.

Top-level app component is necessary for building a structured React app.
Please give priority to this feature.

from next.js.

We're using next.js in two large projects of ours, now, but if anything was likely to prevent us from continuing to do so, it would probably be this issue. Would love to see a fix for this 🙌

from next.js.

@berzniz made this example: https://github.com/berzniz/react-overdrive

from next.js.

@helguita yes.

from next.js.

as commented in #104, I think a good solution would be supporting a _layout.js file like the _error.js.

from next.js.

BTW, I'd appreciate if this issue gets triaged. There's quite a handful of folks who would dearly need this to make Next.js a feasible choice for their project.

from next.js.

With this _layout file we have the possibility to store the global state on the layout component which in turns makes it easier to build an SPA with next.

from next.js.

@L-A Thank you for your reply! However, I think the custom routing trick mentioned above is still like a hack because it's still just one page. Lets say, for example, I have 3 paths: /, /channels and /channels/:channelId which all share the common layouts with exactly the same navigation & footer. Now I want to have a transition animation when I switch between them. With the custom routing approach, I'll need to map those 3 paths to the same page and render different content based on the path name. That means, I'll lose the benefit of the page concept in Next as I have only one page now and no more, for example, page prefetching. It'd be great if I still can have 3 separate pages for those 3 different paths but the "pages" only map to the main content, not the whole layout.

from next.js.

The dynamic import stuff works, but it's clunky, very un-Next.js like in my opinion. What about a higher order component that lets you set a top level page element that gets reused rather than disposed of on page transitions, like so:

// MyLayout.js
import layout from 'next/layout';

const MyLayout = layout(() => {
    return (
       <h1> Header </h1>
       {this.props.children}
       <footer> Footer </footer>
    )
})

//Page 1
import MyLayout from '../components/MyLayout.js';

const page1 = () => {
    return (
        <MyLayout>
            Page 1
        </MyLayout>
    );
};

export default page1;

//Page 2
import MyLayout from '../components/MyLayout.js';

const page2 = () => {
    return (
        <MyLayout>
            Page 2
        </MyLayout>
    );
};

export default page2;

Would an approach like this be technically feasible? It just seems much more in spirit of the Next.js ease of use + convention over configuration.

from next.js.

For anyone who stumbles upon needing page transitions, I've done it pretty easily like this:

Router.onRouteChangeStart = url => {
	const
		{ pathname } = location,
		$container = document.getElementById('container'),
		$clone = $container.cloneNode(true)

	if (~url.indexOf(pathname) && pathname !== '/')
		return

	document.body.classList.add('loading')
	$clone.querySelector('div').style.marginTop = `${-window.scrollY}px`
	$clone.className = 'clone'

	raf(() => {
		$container.parentNode.insertBefore($clone, $container.nextSibling)
		$clone.classList.add('animate-out')
		$container.classList.add('animate-in')
	})

	$clone.addEventListener('animationend', () => {
		document.body.classList.remove('loading')
		$container.classList.remove('animate-in')
		$clone.parentNode.removeChild($clone)
	}, { once: true })
}

And then in your CSS just define the animations like so:

@keyframes fadeOut
	to
		opacity: 0

@keyframes animateIn
	from
		transform: translate3d(0, 15px, 0)

	to
		opacity: 1
		transform: translate3d(0, 0, 0)

#container[class*="animate-"]
	position: fixed
	top: 0
	right: 0
	bottom: 0
	left: 0

	&.animate-in
		opacity: 0
		animation: animateIn 1s .7s ease-in-out forwards

	&.animate-out
		animation: fadeOut 0.1s .3s ease-in-out forwards

This allows you to do seamless page transitions. Could alter it to do left/right slides, top down slides, whatever.

from next.js.

@ngocketit Yep you got some valid points here.
We are trying to accomplish lot of new/cool things with a simple way to build apps.

We choose this routing API based on all those stuff.
It work great for most of the cases, but it didn't work well for animations (and if you are need to keep react state while switching pages)

This is something we are going to deal with after 2.0. That being said, we are not going to give you a React Router like API for routing. Instead, we are going to support dynamic imports.

With that, you could create a layout page which loads modules/pages dynamically. Layout page does all of these based on the queryParams. You can map them into custom routes using our routing API.

from next.js.

@mmmeff I get your point of view, but I don't want to call this a demand:

The actual issue lies in the architecture that currently does not allow for a router with transitions. This is a matter for the boss because it has to be coordinated with many other features and nits (certainly, some of them are WIP and kept secret for a while, Zeit-style 😉). Someone barely involved with this project is simply not able to grasp, and more importantly, decide upon the implications following from a seemingly less complex change. There have been some PRs (#2440, #2613, and more remotely #242) but all of this is moving quite slowly and infrequently.

I want to draw some attention to this thread, being the oldest open issue with many people in the same boat. We definitely need some official direction.

from next.js.

Same, I had to can a month's worth of work because working around this missing feature is a nightmare at scale. I think the devs are really underplaying the importance of this issue.

The silence from the team is a huge disappointment.

from next.js.

@tz5514 You can see here that they are aware of it and want to solve it as well: #3288 (comment) Also the PR #3288 does not seem to solve the issue and it seems there are workarounds for all the problems that were discussed here.

Guys you all get next.js for free, blaming the contributors for beeing silent on this particular issue is just rude. Instead let's discuss on the possible workarounds we have and try to fix it yourself, sharing solutions/hints.

from next.js.

@arunoda Persistent modules aren't the whole story. On the UI side, animating relies on components and their states being diff'ed on render.

v1.2.3 still renders a new stateless component from the top of the tree instead – nothing is preserved under the <AppContainer> on page change.

This doesn't allow a component to be in a certain state, then animate to another when a new page is rendered. It's always discarded and re-rendered as a new component.

from next.js.

Just chiming in here... What I think you guys are talking about is a top-level component. Well this is usually achieved with the <App ...> thing which it seems the whole point of next.js is to abstract away into a "page" based model.

The problem is that there is basically an absolute need for SOME kind of developer-controllable top-level injection point... I mean a lot of stuff just HAS to be in singleton form (it's a requirement of some modules). Like for material-ui it requires this component injectTapEventPlugin from 'react-tap-event-plugin'... and then you have to run injectTapEventPlugin() only ONCE in your application life cycle. But the whole idea of HMR is it keeps your app in a kind of happy zombie mode between rebuilds, so if you stick that injectTapEventPlugin() at the top of a page, it throws an error because it's getting instantiated multiple times.

Now ONE way to handle is a wrapper component used on every page but this is kind of philosophically ugly I guess. Esp if it's not really a wrapper component you need per se... but just a kind of common "header"... the other problem though is the ES6 static analysis of header parts that are already on each page, namely import statements.

So this is kind of a tough problem I think... the question is what is the cleanest way to solve this while keeping one of the main next.js features which is the "page" concept of routing. Am I stating this in a sensible way, or am I confusing the issue?

from next.js.

A layout / animation example would be swell when dynamic imports land.

from next.js.

@rauchg Given the new layout example added last week still exhibits re-rendering on page-change, how does the team plan to solve this problem?

from next.js.

Any updates since next 3 release?

from next.js.

We also require this in almost all of our projects, in the current one for an audio player that is not supposed to restart with every page change. It would be great to get an official solution so we don't have to resort to hacks. Is this on the roadmap? Could somebody comment? @timneutkens @arunoda @rauchg ?

from next.js.

A solution to this would be so nice to have. I'm quite surprised this hasn't been prioritised yet given the level of community interest ;)

from next.js.

@rauchg I've updated nextgram to use Next 2 and custom routing API.
See: #693 (comment)

Here's more information about the re-rendering.

• If you change an actual page, UI will be re-rendered. There's no direct way to fix that.
• If you change the URL but keep the same page (via custom router API), next.js won't re-render the page. With that, you can achieve animation and other stuff.

See this repo for how it render a modal with a route change: https://github.com/arunoda/nextgram

from next.js.

It does seem like a fundamental part of what makes working with React great. To not have a standard approach for persisting components across pages is a real bummer. I feel like we're at an architectural impasse.

from next.js.

Here's an alternative PR that should solve this: #3461

from next.js.

Tried using dynamic imports, but I was unable to achieve anything 😞 Is there a simple example of animating two pages using dynamic imports?

from next.js.

I made a version which uses the _layout.js from the root folder of pages. I want to change some things before I'll make a PR for this. The suggestion by @eirikurn is also very interesting, I'll try to get this working as well.

from next.js.

@paulwehner If you read through this thread, there is a workaround

from next.js.

@hugotox I can't speak for everyone but my use case would be the same as #1509 -- a persistent audio/video player -- so I don't think that would work.

from next.js.

I agree. Honestly, I was considering this framework a couple months ago for my ssr react projects but the lack of this basic feature (at the era of the realtime and spa) pushed me to other horizons.

from next.js.

After developing with next for a few weeks, now I have to look for another framework just because of this missing feature.

from next.js.

I think this would be good. It's already fairly easy to implement I think - see my example of a simple PageFactory component, which is just a higher order component that I wrap my pages in (example). (note this example isn't complete, as ideally PageFactory would implement getInitialProps which would call the equivalent method of the child component).

It would definitely be better to have an optional component that wraps pages automatically, to save users reimplementing something like PageFactory and having to remember to wrap each page.

from next.js.

@mattapperson _document.js only executes server side. Won't work for client side logic

from next.js.

I also have a problem to initiate the common code on every page change and browser reload. My workaround for that is to use both Router.onRouteChangeStart and window.onload event like:

Router.onRouteChangeStart = (url) => {
    console.log('Called every time on page change');
}
if(process.browser) {  // to check if we are on client side.
    window.onload = () => {
        console.log('Called on browser reload or on first page load');
    }
}

from next.js.

I am trying to find an interim solution to having a 'Persistent Sidebar across Pages'.
My understanding, from reading through this thread, is that a new Layout solution might be implemented in 3.x or beyond? Another idea seems to be to integrate the Router more fundamentally with React's reconciliation (for example using unique keys) to get more granular control of which components to re-init?

In the interim, do you discourage from using the 'Shared modules' example for creating a 'Persistent Sidebar'?
https://github.com/zeit/next.js/tree/master/examples/shared-modules

This example relies on storing variables in module scope (vs state) and calling forceUpdate(). It's perhaps not pretty but I think it would do the job?

Any thoughts appreciated :) @arunoda, @OutThisLife, @Xerios

from next.js.

I have come with a very simple solution for this issue. Not sure if fit all cases but it works for me:
Use a common Layout component which will fade in when it mounts. So:

import React, { Component } from 'react'

export default class Layout extends Component {
  constructor() {
    super()
    this.state = {
      mounted: false
    }
  }

  componentDidMount() {
    // trick to make the animation work is to call the set state next run
    setTimeout(() => {
      this.setState({mounted: true})
    }, 1)
  }

  render() {
    return (
      <div className={'animated ' + (this.state.mounted ? 'mounted' : '')}>
        {this.props.children}
        <style jsx>{`
          .animated {
            opacity: 0;
            visibility: hidden;
            transition: all 0.3s ease-in;
          }
          .animated.mounted {
            opacity: 1;
            visibility: visible;
          }
        `}</style>
      </div>
    )
  }
}

Then all your pages must use this and they'll fade in when navigating to them

from next.js.

Just tried using React Transition Group on a top level pure "PageLayout" component which is used in all pages, tried the example of @OutThisLife and all the other workarounds, I even tried to create special components that try to just animate-out the existing content...got nowhere :(

The only solution that gave me a smooth page to page transition in next.js is @berzniz react-overdrive. That even works with history.back. I will dig a little deeper, maybe I can find the magic sauce in react-overdrive so it is combineable with React Transition Group or react-motion to allow any kind of transitions and not only those (awesome) magic-move transitions.

from next.js.

Any update about this? I have arrived at a major roadblock because we can't share components accross pages

from next.js.

@willmeierart It doesn't prevent any native next.js functionality at all.

from next.js.

Thanks, indeed having an external template file sounds simpler than multiple roots. It might help to reword the issue to speak in broader terms of a shared template which doesn't reload? (to keep header, footer, CSS with transitions, Redux Provider, ApolloProvider, etc)

I would also not call such a file _layout, because as mentioned above it could help with other things than visual layout (such as maintaining global state).

from next.js.

Agreed that the routing API makes it possible to do transitions as needed. A top-level component is also available now. And the two are already documented.

To me, that rounds up the issue. 🙌

from next.js.

@kybarg That's a one way of doing it.
I'd like to think about few alternatives and pick the best suits for us.

from next.js.

@MarcMagnin you can't do like that. The name of the module should be an string. It needs to be analyzed statically.

from next.js.

@arunoda any updates on this issue? Next.js 3 is released, but have.'t found any info on it.

from next.js.

https://github.com/rauchg/blog/blob/6efbd2c70c549bba72f7f449208e725814f3a5fb/components/meta.js

Try navigating around rauchg.com you'll see the nprogress loader 😄

from next.js.

I almost finished my implementation of _layout component. Everything's working except the inclusion of the default layout file. I'll make a pull request once I can figure out how the hell the nextjs takes in account default files like _document.js

from next.js.

Demanding changes to FOSS instead of opening a PR is kinda lame, but you're right that people need this feature to make the platform feasible.

It does feel like the devs abandoned work on this problem.

from next.js.

@luisrudge to me, this also seems to be the most coherent way.

from next.js.

Is this duplicate of #50?

from next.js.

This issue aims for a single modifiable root component whereas in #50, the complex strategy of having multiple roots is discussed. With the latter, route transition animations could be hard or at least different to implement.

I would answer your question with no, but feel free to comment if merging the issues would make sense.

from next.js.

How about allowing each folder in pages/ to have a _layout.jsx module. This module exports a layout component for pages in that folder. Nested folders could have nested layout components, a la react-router. The life cycle of these layout component would work like in react router, so they could maintain state across page loads and perform page transitions.

This method is inspired by gatsby, which uses React Router behind the scenes.. But next could take this method further, supporting getInitialProps at every level, e.g. load navigation, sidebar data.

Another interesting point; this pattern breaks in gatsby when nested layouts don't match urls. But with Programmatic API (#291), it would be easy to work around that.

from next.js.

Guys, animations might now have been worked before since we load the same JS module multiple times in every page transition. See: #253

We've fixed that with v1.2.x. So, I assume animations will work between pages without any additional work.

from next.js.

Is this now possible in 2.0.0 beta? I'm looking to do a transition similar to React Router's example here: https://react-router.now.sh/animated-transitions or even something simple like this just to get a starting point would be awesome http://stackoverflow.com/a/40479463/1461204

from next.js.

Client side route transitions are tricky. In order for them to work properly, the page you're linking from has to be certain that the next page has already been loaded.

I think one way to enable this could be by leveraging the imperative prefetching API:

<a> onClick = () => {
  prefetch('/something')
  .then((page) => {
    // render the `page` component & trigger transition
    // then push before or after the transition completes, up to you
  })
}</a>

That said, we'd also need some way to handle the pop event in a custom way.

If you really want smooth transitions without introducing so much complexity (that has to do with the uncertainty of pages being loaded or not) you can make the routes that need transitions a single page.

This is what the nextgram example shows (https://github.com/zeit/nextgram). A certain route can take on different URLs by calling this.url.push. componentWillReceiveProps then will get called as the url object changes. New entries are introduced into the history stack, but they're all associated with that one page.

Then notice in render:

This is how we're able to show the photo as a modal, and if you hard-refresh, as a permalink page.

Another way of doing this, declaratively, is by using as in <Link>:

<Link href="/index?section=1" as="/section-1">Section 1</Link>
<Link href="/index?section=2" as="/section-2">Section 2</Link>

Since it'll end up being the same component and the same state, you can transition easily.

In both cases you'll want to make sure that /section-1 and /section-2 point back to the index page by using the server API, so that server-rendering works correctly.

from next.js.

I think that's a good-enough workaround for now. It should give you the same experience you see in that React Router example because it assumes that the 4 components are already loaded.

If you have any other ideas, please let me know. For our use cases the transition stuff is not a huge priority, but always open to elegant solutions.

from next.js.

Closing. Will re-open when needed.

from next.js.

I'm about to port one of the existing project to Next and one of the requirements is that we need to have animation when transitioning between pages that share the same layout (with navigation & footer) but different main content. So having this is a must for the project (as required from the product owner). But if that can't not be done with the current version, I'll need to look for other solutions, which is bad since Next is very nice to work with.

from next.js.

@ngocketit If you read up a, bit, there are now reliable ways to do it. Make sure to include "next": "^2.0.0-beta" for now and you should be good to go.

from next.js.

@ngocketit Your understanding is correct, however you can make your own routing path with different pages.

In https://github.com/arunoda/nextgram, the requested paths are different routes: /, /profile?id=[id] /photo?id=[id].

What you could decide to do is make the loaded app add a frameless argument to the supported URLs it requests, and extend your page component to return either the full page (first request) or just the main content (app request) according to that.

(This is just napkin planning to illustrate the idea. Hopefully it helps you make the call whether next fits your use-case or not!)

from next.js.

Agreed with @ngocketit that the routing API is pretty hacky here. It only solves a small subset of the problems being discussed in this thread.

I really don't understand the reluctance to add a _layout.js that renders props.children inside of it....

KISS!

from next.js.

I'm discovering the possibility to create PWA with Next.js and the possibility to re-rander not the whole app is crucial.
@arunoda will support of dynamic import in next.js mentioned here include server side rendering?

from next.js.

@andbas yes. It supports SSR as well.

from next.js.

@arunoda I have much free time to work on this issue as I need this very bad 😄 I just need some kind of road map so I didn't go wrong way solving it. Could you please point me the best way to do it? Thanks.

from next.js.

@kybarg Frankly we don't have a proper way to do this unless you render all of your components in a single page.

We try to solve this with dynamic imports (hence there's only one main page).
Here's the branch for that.

We implemented SSR with that but it's far from a good implementation.

from next.js.

@arunoda I like idea of having some <Layout> wrapper by default with ability to change it in _layout.js.

from next.js.

@arunoda I had a time to play with example you posted, but right now it execute import on a client side. There is no easy way to return full page with imported component from server.

I thought about nesting in pages folder, e.g. have pages/home.js that implements "layout" and pages/_home/child.js that implements page itself and available though /home/child route.

from next.js.

One of the ideas I'm playing with in my mind to retain the component and its state, so that it could be animated for example, is to put a key on the top level element returned from render.

If the key and component type match, then we retain instead of dejecting.

Or, in other words, imagine that the default model Next.js has right now is that we always retain, but we assign a "random key" to each page, therefore it unmounts and mounts the new one when we transition.

from next.js.

By the way, maybe this is something we have to do statically (as a key property on the exposed function / class), and maybe we can't do it with render. Since I haven't really implemented this, I'm only commenting on the high level idea

from next.js.

spent the last couple of days trying to port an existing app of mine to use next.js mainly to have an easy entry to ssr redux and webpack

#1674

seems like my issue is related to this here and something like a _layout.js for wrapping around each page sounds a bit like what i need, my latest approach was trying to use a custom server which only uses one page which in turn embeds a react-router which itself didnt work that well and broke SSR because my pages have async stuff and react-router doesnt call the getInitialProps which i could use for that…

from next.js.

@rauchg You could assign a unique static key to each page based on its file path in that scenario. Where does the current implementation differ from an architectural standpoint?

from next.js.

@arunoda is this issue something you are planning to get out before 3.0?

from next.js.

I couldn't see _document.js mentioned in this issue. What's missing beyond this?

To override that default behavior, you must create a file at ./pages/_document.js, where you can extend the Document class

// ./pages/_document.js
import Document, { Head, Main, NextScript } from 'next/document'
import flush from 'styled-jsx/server'

export default class MyDocument extends Document {
  static getInitialProps ({ renderPage }) {
    const {html, head} = renderPage()
    const styles = flush()
    return { html, head, styles }
  }

  render () {
    return (
     <html>
       <Head>
         <style>{`body { margin: 0 } /* custom! */`}</style>
       </Head>
       <body className="custom_class">
         {this.props.customValue}
         <Main />
         <NextScript />
       </body>
     </html>
    )
  }
}

from https://github.com/zeit/next.js#custom-document

from next.js.

Any news about dynamic imports?

from next.js.

from next.js.

awwwww... I'll try it now!

from next.js.

Awesome, so I've tried import and it seems to work fine but how do you refresh a dynamic component? (https://github.com/zeit/next.js/tree/import-then/examples/with-dynamic-import)
I've tried such thing so far:

const DynamicComponent = withImport(import(this.props.dynamicComp))

But I got 409:22-55 Critical dependency: the request of a dependency is an expression

from next.js.

Thank you @timneutkens, I saw that on my ventures around this thread again. I was hoping for a simple example showing a fading animation between two pages. I guess I don't understand how dynamic components will help with animating pages?

If something like this could be done with dynamic imports that would be so awesome: https://github.com/maisano/react-router-transition I'd be willing to build something like this, just need some pointers on how that could work with dynamic imports 🙏

Huge thank you for all of the hard work so far 🙏 just hoping I can add some polish with route transitions 😁

from next.js.

As I wrote in #2091 this issue prevents you from having something like a navbar without constantly unmounting/remounting.

This is a problem for us because our top level container manages a websocket connection and has to disconnect/reconnect on each page transition.

@timneutkens What's the status on a _layout.js file? This issue is the only thing stopping us from using Next.js in production!

from next.js.

@scf4 what prevents you from using _documet.js for this?

from next.js.

Sorry if this has already been answered above, but I would like to have one page slide out to the left of the screen, and the next page slide in from the right. So the current page and the upcoming page move together at the same time and as one slides out the next one slides in.

Is there a recommend approach on how to do this with Next.js or how to do it with React.js in general?

from next.js.

@timneutkens Is there a recommended approach for page transitions... to have current page slide out and next page slide in. So something like this: https://github.com/maisano/react-router-transition? When do you anticipate having an option like this included in Next.js? If I'm trying to replicate a SPA mobile experience, this becomes a fairly important requirement.

from next.js.

@OutThisLife Awesome, thanks for sharing. You wouldn't happen to have an example repo you could share that includes the code snippets from above, and an example page/component that you are sliding in and out?

from next.js.

I wonder, could @OutThisLife and the react-overdrive implementations be combined? I don't know the details of how overdrive works, but I'd prefer not to have to colocated all of my pages that need transitions.

I'm also unsure how performant the clone approach is, but I'm down with it in theory.

from next.js.

Having implemented OutThisLife's approach naively across pages (not using the same-page workaround), it runs into two big issues:

1. The $container which has an animate-in class applied immediately loses that class as the container is unmounted and remounted across pages, so it does not animate.
2. The $clone does not retain its local styles through its animation as those styles are unmounted when the container it was cloned from is unmounted.

from next.js.

Submitted my pull request. Now we wait...

from next.js.

Regarding the same-page rendering example with nextgram, it's not really a workaround as it only works if the page that's being linked to is a modal (floating over the page), which most pages aren't.

And of course that your entire app then has to be architected around these route transitions existing on a single pages/index.js file.

Here's to hoping @Xerios has an approvable approach 🤞

from next.js.

@mherodev I use this on a site in production, so something must be up with your application of the system.

I have it setup to where index.js houses some data and props cascading to a main.js which houses the #container which wraps whatever page component that I need.

To show a very dumbed-down example:

index.js

import { Router } from '../routes'
Router.onRouteChangeStart = url => ...

export default class Index extends PureComponent
    render() => <Main {...data}>

main.js

export default class Main extends PureComponent
    render() => <div id="container"><Page {...data} /></div>

The routes file exports next-routes so I wonder if that has something to do w/ it.

If time allows I'll setup a dummy repo.

from next.js.

Sorry, I was setting it up without doing the single page approach, if that wasn't clear.

With a single page, I imagine those transitions work correctly.

from next.js.

Question - There are a few workarounds currently, but what is the best one for handling notifications and other persistent components that shouldn't remount? Was thinking about either using @Xerios solution or hacking react-router v4 in, but didn't want to architect the app in a way that may change soon. Any update/recommendation?

Or maybe just a commentary that next.js is not for more advanced apps that require things like route changes during a video/phone call, notifications, etc? Not an issue, just trying to decide to use next vs others. Thanks!

from next.js.

@lapidus Shared modules should work fine for your case, I'm doing the same thing.
@sbr464 The reason why I made my change was because, like you, I was unable to find any existing ways to solving my problem with persistent components ( notifications and alerts ). Due to this and few other small things, I had to switch back to using purely react. Didn't take me more than few hours.

I'll reconsider using nextjs once they improve its flexibility 😃

from next.js.

I'm in the same situation at the moment. I'd really love to use next framework for my project, but I have to admit that I'd really miss the layout support.

from next.js.

@OutThisLife Great job on the page transition example!

But, with this approach, it is intrusive to page component. If there is some props initialization work, it has to be done in one page getInitialProps. To enable lazy-props-initialization on each route, basically it means to re-implement next.js logic in application layer. Any better idea on that?

It looks better solution is to have next.js support such transition customization.

from next.js.

@OutThisLife Sorry, but we haven't gotten all the way to being able to implement transitions declaratively using react-motion, Animated, react-transition-group, react-move et al. just to throw plain DOM elements around because transitions don't seem to fit into the Next.js concept.

Just to be clear, this hate does not go towards your workaround — rather, I'm disappointed to learn that some people are apparently praising this solution instead of criticising that this is still not possible with Next.js v3. This is even an official example.

@timneutkens, any news or statement on this?

from next.js.

@dlindenkreuz Completely agree

from next.js.

@knpwrs correct, my solution is for cases when mounting/unmounting a common Layout component doesn't matter

from next.js.

I've just come across this issue as well. I have a websocket connection and toast notifications that should be persistent across pages - at the moment neither seem to be doable with next.js. Would love to see a solution in the near future as it seems like lots of people are hitting this problem, but at the moment it doesn't seem to have really been picked up on. It'd be great for it to be prioritised / put in a roadmap so it's easier to make product decisions at our end - I'd hate to move away from next.js but this could be the real blocker 😔

from next.js.

If you guys use redux, you can initialize websocket in the store, so that will be persistent across pages, see the official example https://github.com/zeit/next.js/tree/master/examples/with-redux

from next.js.

While we'd need it for transitions as well, I think there are way more usecases where this could be very beneficial, like eg @knpwrs's audio player. We also have a usecase where we'd need to persist a canvas/WebGL context where this would come in super-handy. Skipping the pages-feature for it costs like half of next's goodness.

from next.js.

@OutThisLife -- the solution works quite well for my use-case, in conjunction with redux to maintain global UI variables, at least early on in the project, so thank you! But along the lines of @mocheng's comment -- am I correct that the solution basically prevents all Next's code-splitting, prefetching, etc. -- perhaps even true SSR -- from working?

from next.js.