Easy layout implementation

[simonedelmann]

What do you want and why?

It would be great to have a simple mechanism to import a layout from /app/layouts folder.
I would prefer something like this:

// within a page component file
import FooLayout from 'app/layouts/foo'
export Layout = FooLayout

If it is not possible to do export Layout = ..., an alternative:

import FooLayout from 'app/layouts/foo'

const FooPage = () => <div>Some content</div>
FooPage.Layout = FooLayout
export default FooPage

Possible implementation(s)

This is how I use the layout in a project right now:

// _app.js

import { AppProps } from "blitz"
import { NextComponentType } from "next"

export default function MyApp({
  Component,
  pageProps,
}: AppProps & { Component: NextComponentType & { Layout?: React.FC } }) {
  if (!Component.Layout) {
    Component.Layout = ({ children }) => <>{children}</>
  }

  return (
    <Component.Layout>
      <Component {...pageProps} />
    </Component.Layout>
  )
}

Suggested improvements:

• It would be great if the custom intersection of AppProps could be build into blitz.
• It would be great if a default empty layout would be provided by blitz out of the box.
• Not using Component.Layout but a separated Layout parameter

This could end in an _app.js like this for the end user:

import { AppProps } from "blitz"

export default function MyApp({Component, Layout, pageProps}: AppProps) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  )
}

[merelinguist]

This is an interesting idea! I don’t know whether it’s within the scope of Blitz, but it’s certainly something we could write docs on. Gatsby used to have something like this, but they removed it in v2 for these reasons. Definitely open to discussion though!

[ryardley]

I am wondering what is the main advantage here? avoiding re-rendering? I think syntactically it is possibly more obtuse and confusing as having the Layout within the Page communicates the structure of the render tree clearly without having to know anything about how next does rendering. Eg.

import FooLayout from 'app/layouts/foo-layout'
// I know the following wraps content by looking at this
export default () => <FooLayout><div>Some content</div></FooLayout> 

import FooLayout from 'app/layouts/foo-layout'
const FooPage = () => <div>Some content</div>
// If I know nothing about the framework how do I know what this means?
FooPage.Layout = FooLayout 
export default FooPage

[merelinguist]

Right I agree with @ryardley. This was basically the main reason Gatsby removed it, since it’s a weird obfuscation of what your component tree will actually look like, and isn’t how React normally behaves. The only advantage in my eyes is what you mentioned–that it prevents a re-render. I guess it’s a question of whether we feel this is a sufficiently common use-case to build it into Blitz, when it’s already possible without a special implementation.

[merelinguist]

There’s a good article on how to achieve this normally with Next (and therefore Blitz), and why you might ever want to do it here: https://adamwathan.me/2019/10/17/persistent-layout-patterns-in-nextjs/

[ryardley]

Also what happens when you want to add props to your layout? This is easy.

import FooLayout from 'app/layouts/foo-layout'
export default () => <FooLayout title="My great page"><div>Some content</div></FooLayout> 

but would be hard with an export

[merelinguist]

Personally I’d say the smaller the Blitz API surface can be, the better.

[ryardley]

@merelinguist Totally agree

[simonedelmann]

@ryardley @merelinguist Thanks for answering the issue! I do get the point. Probably I hadn't thought about this enough.
In my case right now I do need a persisted layout, so I do need to put the layout in _app.js. But many people maybe don't need that.
But I am wondering, why do we have a 'layouts' folder per default then? What is special about the components in there compared to 'components'? (Why not use 'components/layout'? Seems more logical to me.)
So when layouts are not implemented in a special way (which I can totally understand), I think we need a section in the docs, how to use that folder.

[merelinguist]

cc/ @flybayer re the layouts folder?

[flybayer]

Good discussion everyone! Currently the layouts folder is nothing special, just a convention. I'm open to moving it inside app, although I think app/layouts would be better than app/components/layouts so it's less nesting and is immediately apparent where layouts are when looking inside the app the folder.

Originally I was thinking to basically include Adam's article mentioned above in our docs. But I'm open to adding some type of built in layout support into Blitz since it's so common. But I don't have a good sense of how command persisted layout is needed.

@simonedelmann what are you needing persistent layout for? Is it public facing pages like documentation or is it inside an app with a login?

For our auth recipe that adds username/password authentication, I've been thinking that recipe will also add <AuthenticatedLayout> and <UnauthenticatedLayout> components. But I haven't thought much about the best way to do this yet.

[simonedelmann]

In my case (basically a SPA) I only have one layout which almost all pages (= all but Login/Register and Error) share. The layout contains some navigation and will contain information based on the current authenticated user (when authentication is finished). I plan to add a search box, therefore I need the persisted layout.

[flybayer]

Why does the search box need persisted layout?

[simonedelmann]

I would like to persist the search when opening one result, in case the user wants to switch to another result.
Another reason: I probably need to fetch data from the database to display the navigation. Therefore persistent layout seems to be the easiest way to avoid refetching on each page load.

[merelinguist]

I don’t know the internals of react-query well enough, but I’m pretty sure the cache will handle that for you. As for persisting a search input, that’s not something you’d typically use the persistent layout trick for. It’d be much easier to do something like save the input in localStorage. You can see what that looks like in the gui.

[simonedelmann]

Thanks! So probably I don't need a persisted layout. :)