[RFC] remove our special layout components in Gatsby v2 #3830
Comments
|
No |
Nope. Nuke it. Simpler is (generally) always better |
No. |
|
No |
|
I'm using it right now. I've got content in multiple languages and I've got a layout per language where I load language data and translations: // src/layouts/de.js
import React from 'react';
import { addLocaleData } from 'react-intl';
import localeData from 'react-intl/locale-data/de';
import Layout from './index';
import messages from '../../data/translations/de.json';
addLocaleData(localeData);
export default (props) => <Layout {...props} locale="de" messages={messages} />;// src/layouts/en.js
import React from 'react';
import { addLocaleData } from 'react-intl';
import localeData from 'react-intl/locale-data/en';
import Layout from './index';
import messages from '../../data/translations/en.json';
addLocaleData(localeData);
export default (props) => <Layout {...props} locale="en" messages={messages} />;and so on for a few other languages. In posts.edges.map(({ node }) => {
const id = node.contentfulid;
const locale = node.node_locale;
return createPage({
path: `/${locale}/blog/posts/${id}`,
layout: locale,
component: path.resolve('./src/templates/post-page.jsx'),
context: {
id,
locale,
},
});
});Is it possible to do it with a single layout, so that I don't have to load language data and translations for all supported languages? |
|
@szimek maybe I'm mistaken but would it be easier to have an array like |
|
@mattferderer Maybe ;) How can I pass data to layout context in |
|
Oh God, this is a tricky one...while I have yet to explore layouts more, I can see it's use in unique layouts. However, I think that in itself is more for templates than layouts. I think that unique layouts are the minority, and modified footers and headers could change depending on template, I think. |
|
This could potentially be useful in advanced use cases (for example, if an agency or SaaS platform wanted to make a site manager a la WordPress Multisite or whatever it's called). That being said, could it be extracted to a plug-in so that multiple layouts we're opt-in only? I agree that simplifying it would probably benefit the vast majority of users. |
|
I'm working on a website using two page layouts. I first created two Gatsby layouts, but I end up using a home-made component dedicated to templating and used inside the pages. Why ? Because I needed to pass some data from the page, to the layout. So... I don't have a definitive opinion about the multiple layout things, but:
@KyleAMathews THIS is a real issue. Having a single entry point for the whole app would be a great feature. Having multiple entry points makes maintainability harder and increase the chances of doing a mistake.
@szimek You could use only one layout on let the pages handle the i18n locales. Just make one page by language during build time (onCreatePage) and pass them the concerned language via |
|
@monsieurnebo I don't want to hijack this thread to discuss the details of adding |
|
@szimek Let switch to Discord to avoid the "hijack" :) |
|
I don't know what this is so I'm probably not using it... 😅 @szimek I heard about plug-ins to build multilingual websites, might be a better approach. If you're interested, look for "i18n Gatsby" on the web 😉 |
|
@thomaskuntzz Thanks, but I already got a working solution that uses multiple layouts 😏The question is how to achieve the same with just one. gatsby-starter-default-i18n uses multiple layouts. gatsby-plugin-i18n only creates routes and in its docs it also mentions: "you can use different layouts for each language if you want to". There's also https://www.gatsbyjs.org/blog/2017-10-17-building-i18n-with-gatsby that doesn't mention layouts at all, so I guess it is possible to do using just one layout, but they are using |
|
I have never used extra layouts before, but now I think that most of us would be very curious about an official guide for internationalizing websites with Gatsby. |
|
@KyleAMathews what are the pros for having a layout? If layouts are the on table, an alternative thought night be to drop layouts completely. Not only has there been confusion with multiple layouts, but there is a not a The Right Way™ to use layouts. This means we keep trying to make them more flexible including pushing up props, rerendering on prop changes, using multiple layouts, etc. Flexibility is great, but I think this is just better suited to be done with react. It is already seeming to be turned into a higher order component. We can opt to take care of this with react, and simplify both the teaching and the maintaining code efforts. I suspect it is easier to optimize webpack, preloading code and caching if there is only one smart component. Layouts are currently handy to import global css. If we scrap layouts, we can import css via the higher order component. Alternatively, it might be interesting to add an API to take in global css. With the new webpack, this could make chunking global code out for long term caching something that comes nearly out of the box. If we axe layouts, we only have one place for "top level queries". This seems like it should make graphql a bit easier to grasp, and make fragments more important to use. Both which I think are worthwhile. Lastly, we have had the on and off discussion regarding the idea of themes for a while. I think that idea is difficult to reason about when sites are composed in so many different ways. If we axe layouts, our ability to compose a site isn't hindered (because React), but I would surmise that many sites will be composed very similarly. Gatsby-image is great because it handles the annoying stuff, and does all the things that most people want. If everyone is using a higher order component for their nav and sidebar, it would be great to create a theme that sets global css, and gives you a handful of components to use. Essentially handling the "shell" aka the annoying parts for those of us with a poor affinity to design. We could even abstract to the point that someone could bring markdown for the homepage and a folder of markdown blog posts. The combination of themes handles the components and templates. The theme (or meta themes composing multiple themes) could just be added as an npm package, and they get any updates to it. Being able to track a package rather than 20 is something requested multiple times with gatsby-starters. Essentially emulating the approachability of create-react-app. Lots of thoughts I've been considering for a while. Hopefully the translation from brain to text holds true. Happy to hear other thoughts on the matter. |
|
To @jbolda's point, when I built my site with Gatsby, I didn't use a layout at all — I ended up just building a (This is because I got carried away before reading the rest of the docs, not because I had any kind of opinions about how things should be done. 😅) Is there anything in particular that an official Gatsby layout does that isn't possible with a |
|
Shouldn't |
|
Agree about removing layouts as they make things more complicated than they need to be by making it gatsby specific construct instead of utilizing general react solutions. Obviously we should then document clear migration path for projects that utilize multiple layouts. On the side note - we don't have actual data to backup those 99% - 1% numbers, right? Maybe we should consider gathering statistics about usage of gatsby apis during build time so we could make more informed decisions? Difficult subject as that would need to be opt-in (IMO) and then those statistics would certainly be skewed. |
|
I'm skeptical of the 99% number, I've used multiple layouts in all my gatsby sites... Are they essential? No but neither is most of the defaults in Gatsby I've found that they provide a much better api tho for starter projects of specific sorts since you only need to add the layout file vs an if branch in one parent layout. I feel like it's a good feature for tools or template authors and doesn't get in the way of the single default api if you don't need it Just my 2cents :) |
|
I posted this on Twitter but I'll paste it here as well. I think multiple layouts should stay. They are still useful for websites w/ page layouts that differ wildly from default like e.g. if news sites/blogs want to create a longform article with a specialised theme. I couldn't think of any other way to implement it other than using multiple layouts. |
The use cases I see for multiple layouts are that they don't reuse the same assets or css (hence why they are considered a different layout, in a different folder 😄). So this makes sense to me...
I currently use 2 layouts for my personal site and another company website I'm working on is intending to use the multiple layouts for monthly promo landing pages that are out of the regular website's flow. While I agree you probably can conditionally render these scenarios, I'm pretty sure it'd require a lot more code than just leaving in the support for multiple layouts. We could also create these pages as one-offs but I wouldn't be looking forward to that... Layouts seems like one of those things that has it's own time and place to be used... maybe it isn't what a good portion of people will use but when you come across a the time to use it you're glad you had it. So sure, they're not 'essential' and you can work things without them, but I don't think Gatsby would be moving in the right direction by removing this feature and I disagree that'd it would somehow lead to less complicated code. Maybe instead the feature should be better explained in the documentation and when/why/how it could be used? |
|
@resir014 @South-Paw I haven't looked at the source for layouts, so I don't know if this is possible, but couldn't we get all the benefits for minimal trade-off if there was a This has the following benefits:
We'll need @KyleAMathews to confirm that moving multi-layout to a plugin is feasible, but — assuming it's possible — does that seem like a win-win to everyone? |
|
it'd probably be fine to move to a plugin but i'm not at all sure that's possible with the current api... |
|
@jlengstorf that seems like a good idea for best of both worlds. I just don't want to see this functionality disappear completely from v2 as it really does have valid use cases and provides a valuable feature/point of difference. 👍 |
|
Keep multi layouts and document it as an advanced feature. Removing it would add additional complexities for large projects because of conditional rendering in the only layout available. May need some mechanism though to inject common styles. But that's one time technical problem rather than a multiple use case problem. |
|
Not having multiple layouts is a huge problem for all sites other than personal portfolio/blogs. If that is the usecase that gatsbyjs wants to chase, then that's your choice - but essentially its a signal that gatsby is not intended for anything bigger. Let me explain - this feature is intended for marketers and not developers. Every half-decent (or even quarter-decent) content or ecommerce site has to create zillions of landing pages. For example "Valentine's Day Offers for your 70th anniversary!" versus "First Valentine's Day ?". The design, layout, usability requirements for each landing page is substantially different. Ideally, you should be able to use the powerful layout tools inside Gatsbyjs or Hugo to build reusable templates. So that my marketing team can easily edit a markdown/yaml page, choose a template and have a new landing page! Basically, multiple landing pages is what makes a CMS versus a blog. Jekyll isnt too good at this - it was intended as a developer hosting blog pages on github pages. Hugo does this brilliantly - https://gohugo.io/templates/views/. Gatsbyjs is very hard to set up like this (actually this is something i asked for in early days of trying out hugo -> gatsbyjs). I'm not sure if the documentation is a little hard, or if the process itself is too complex in gatsby. But this is NOT an "advanced feature" (tantamount to saying - its not super important). It is a central question in where do you see gatsbyjs evolving - does it stay a blog for developers ? or does it go towards a full-fledged CMS for marketers. |
|
Thank you for everyone's comments! Really helped me think through things over the weekend and today. Some specific replies then an update on what I'm thinking. @pieh @jquense I did make up that number... :-) I guess I've never used multiple layouts so extrapolated with bit of hyperbole on top. @szimek thanks for bringing up the details of your i18n site. That helped me clarify one of the roles of layouts which is groups of pages need a way to specify common data and other dependencies which are on the critical path for loading. You can't lazy load translations as then components depending on the translations will break. @jbolda & @jlengstorf & @pieh thanks for questioning the need for the abstraction altogether as it made me think back to why I added it in the first place. Let's go back to first principles. Gatsby thinks in terms of "pages". Which has a path and a React component responsible for rendering that page. Pages can import code and other things through webpack plus define a GraphQL query to pull in data from Gatsby's data layer. I originally started Gatsby v1 without any "layout" concept. But added it (as I remember) as I wanted both a common way to add a header/footer to sites (mimicking a feature in Gatsby v0). After v1 launched, we added support for GraphQL queries to layouts + multiple layouts #1503 @jbolda & @jlengstorf & @pieh raise a good question in why do we have layouts at all instead of just using normal React composition and having a Part of the reason is this was in v0 so I ported it over. I think I added it in v0 as it's a common idea in other static site generators. In retrospect I agree now with @jbolda & @jlengstorf & @pieh that it never made sense as composing React components directly is the native React way of doing things and superior. Another reason is it's an explicit way to code split data & code that are necessary for sub-sections of pages. E.g. @szimek's i18n example — each language layout is an entry point for those subsets of pages. But this isn't a great reason. Code splitting is great but a custom ad-hoc method doesn't make a lot of sense. What do we want?
This is easy to do with vanilla React e.g. // page-1.js
import React from 'react'
import GlobalLayout from '../components/global-layout'
import SkinnyLayout from '../components/skinny-layout'
export default () => (
<GlobalLayout>
<SkinnyLayout>
<div>Skinny page</div>
</SkinnyLayout>
</GlobalLayout>
)// page-2.js
import React from 'react'
import GlobalLayout from '../components/global-layout'
import WideLayout from '../components/wide-layout'
export default () => (
<GlobalLayout>
<WideLayout>
<div>Skinny page</div>
</WideLayout>
</GlobalLayout>
)The layout components are optional, you can nest as many as you need, etc. They'd easily solve problems like i18n and any other layout setup you can imagine. The one place plain vanilla React layouts fall down is GraphQL data. A common thing layouts do is query global metadata e.g. the site name to put into the Imagine if we had syntax something like the following: import React from 'react'
import Helmet from 'react-helmet'
const metadata = require(graphql`
siteMetdata { title }
`)
export default () => (
<div>
<Helmet title={metadata.siteMetadata.title} />
Hello world
</div>
)With a bit of babel magic, we could turn the "require" into a something that leverages a special webpack loader which runs the query and returns the data as normal (btw, I haven't thought this part through thoroughly so please poke holes) With this new ability to "require" data from a graphql query, it'd be easy to use normal React components as layouts and easily add data & code onto the critical path for all pages or sub-sections. Also, in webpack 4, the CommonsChunk plugin is getting smarter so we should be able in the future to further fine tune further how we generate and load bundles. Thoughts? Anything I'm missing? Questions |
|
@sandys we're definitely not just a developer blog engine :-) The purpose of this issue wasn't to eliminate multiple "layouts" but to rethink how we're doing this so it's more React-native + less error prone as I'm tired of answering questions about it :-) I don't really understand what that Hugo docs page is describing so I'd love it if you could open another issue where we discuss how to accomplish whatever Hugo is doing there in Gatsby. Would love to create a docs page teaching the technique for people coming over from Hugo! |
|
Hi Kyle
Thanks for making this position clear. We can now stop holding our
collective breath !!
Hugo invents its own templating rules engine and a precedence order.i would
go so far as to say that it is in some way inspired by WordPress.
Since you guys are building from a React base, it would not be too
important to replicate it. However there are a few important points that
need to be taken care of:
1. Precedence order - I don't think Gatsbyjs does this (atleast I couldn't
find any). It's important for layouts to have a precedence order. This is
the first thing you should think about when you architect your layout
engine - you will invariably have to face questions about "how do I exclude
these pages or directories from X,etc etc"
2. Directory structure - mental model of humans is to create nicely
separated folders. You should have a powerful system of matching folder
structure to templates. Graphql can potentially be very powerful here.
Shameless plug: you will need
#3727
3. Minification and asset pipeline - I may not use one css framework in all
my layouts. If your asset pipeline is designed around minifying EVERYTHING
together, then you are going to have performance problems. This becomes
especially relevant if you're also doing cache busting urls.
Having played with a bunch of these, I believe if you get these three right
- everything else is just layers on top. But YMMV.
…On 06-Feb-2018 12:16, "Kyle Mathews" ***@***.***> wrote:
@sandys <https://github.com/sandys> we're definitely not just a developer
blog engine :-) The purpose of this issue wasn't to eliminate multiple
"layouts" but to rethink how we're doing this so it's more React-native +
less error prone as I'm tired of answering questions about it :-)
I don't really understand what that Hugo docs page is describing so I'd
love it if you could open another issue where we discuss how to accomplish
whatever Hugo is doing there in Gatsby. Would love to create a docs page
teaching the technique for people coming over from Hugo!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3830 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEsU_5melMWclaYvd4EBNNAlVfvr78nks5tR_UqgaJpZM4R3wR8>
.
|
I haven't needed to work with something like this before — you can already choose page templates easily enough with
Yeah, solving #3727 would be sweet.
We're waiting on webpack here to make CSS a 1st-class citizen so CSS splitting is natively handled https://webpack.js.org/vote/ |
im afraid that's not precedence order in its entirety. Do you "have" to specify the template for each page ? Or can I set it at a directory level. So I can choose to have a template for this page, but if not specified, then picks the template set at the parent directory... and if not specified, then its parent and so on.
well.... you can do this today. all you need is the asset pipeline to generate independently for each independent template. I'll take the punishment in exchange for the flexibility (I'm the one asking for independent templates, am I not!). When CSS splitting comes, this becomes 100X faster that's all. |
I like this idea! The top 3 things I like about Gatsby are:
Gatsby's goodness comes from React, GraphQL and the out of the box optimisations! |
|
This is me just throwing out an idea without understanding all the nuances about it - maybe split createpages into two : createpages and renderpages. another advantage of splitting renderpages (if it can be done) is that this can work with the asset pipeline to create separate assets for each template. |
@KyleAMathews, I was also thinking about that as well, but didn't want to sidetrack the conversation too much! I think global data vs local data is very easy to reason about. I was thinking it may be worthwhile to embrace "global" graphql queries. We could specify them in Gatsby-node.js perhaps? Now, keeping things React-y as possible, props is kind of the local data. React recently has made an effort to tighten up context. I think this would fit perfectly in this case. Global graphql just gets piped into context. It would allow you to grab it from anywhere in the tree. On another note, based on @sandys's explanation, precedence order actually sounds like v0 templates. |
|
@KyleAMathews <https://github.com/kyleamathews>, I was also thinking about
that as well, but didn't want to sidetrack the conversation too much! I
think global data vs local data is very easy to reason about. I was
thinking it may be worthwhile to embrace "global" graphql queries. We could
specify them in Gatsby-node.js perhaps?
Now, keeping things React-y as possible, props is kind of the local data.
React recently has made an effort to tighten up context. I think this would
fit perfectly in this case. Global graphql just gets piped into context. It
would allow you to grab it from anywhere in the tree.
Is this a usecase for Apollo or Redux with Graphql. I personally don't
think Gatsbyjs should reinvent the wheel for global queries.
I don't join that Gatsbyjs should definitely build in global support on top
of Apollo or Redux and integrate with Graphql.
Perhaps this is a new issue ?
|
|
@sandys yes — please start new issues if you want to talk about something new |
|
@jquense what do you think about the idea of introducing a new graphql loader for webpack? |
KyleAMathews
changed the title
|
Maybe a bit late to the game, but I wanted to add a use case I didn't see in the discussion yet. I am trying out gatsby for an almost entirely dynamic site, with user-specific data being pulled in from a cloud graphQL service, using apollo. I'm sure this will be solvable in some other way, though (it's components all the way down, after all :-)) so I'm not lobbying for keeping layouts. Having hooks in place that allow for (both build- and runtime) graphQL-based customisation of themes / css / <head> / ... is probably a more flexible and intuitive approach anyway. |
|
I'd like to add something. I am developing a CLI that uses Gatsby under the hood (for non technical users). The directory that the users will manage content in will contain only markdown files. All templates/styles/resources are provided via a npm package. With the I hope we can preserve this use case. On a side note, I actually like layouts. I disagree with them being inherently confusing. |
|
Sounds like a cool project! Layouts would just be normal component. You'd just wrap your page component with the layout component of choice. If you want users to be able to select a layout component, you could add logic for that to your |
|
Hey y'all. Been thinking about this more and have a new proposal for the syntax for making static queries. Previously I suggested a syntax like this: const metadata = require(graphql`
siteMetdata { title }
`)With the idea being that we leverage webpack to do the hot reloading of data in development. But as @m-allanson's investigations are showing in #4555, skipping webpack for data completely let's us do some crazy speedups. So I went back to the drawing board and came up with the following: import React from 'react'
import Helmet from 'react-helmet'
import { StaticQuery } from 'gatsby'
export default class ExampleComponent extends React.Component {
render () {
<StaticQuery
query={graphql`
{
site {
siteMetadata {
title
}
}
}
`}
render={staticData => (
<div>
<Helmet title={staticData.site.siteMetadata.title} />
<h1>Welcome to {staticData.site.siteMetadata.title}!</h1>
<p>We hope your stay is pleasant.</p>
</div>
)}
/>
}
}Just like with our current GraphQL implementation, we'd extract the graphql queries and run them for you. You'd be able to use fragments, etc. The only difference is you can't pass arguments to the query (hence the name, staticQuery :-)). During development, we'd hot-reload changes to the query & underlying data. Then in production, we'd do a cool optimization. We'd have a babel plugin which compiles the above into something that looks like: import React from 'react'
import Helmet from 'react-helmet'
import { StaticData } from 'gatsby'
import staticData12513 from './staticData12513'
export default class ExampleComponent extends React.Component {
render () {
<StaticQuery
data={staticData12513}
render={staticData => (
<div>
<Helmet title={staticData.site.siteMetadata.title} />
<h1>Welcome to {staticData.site.siteMetadata.title}!</h1>
<p>We hope your stay is pleasant.</p>
</div>
)}
/>
}
}There's now a little packet of JSON attached to the component! Also, the static file name would be a hash of the query so on the off-chance you reuse a query, webpack 4 would split out the query result module into a new chunk that's shared between components. I think this will work for all the existing layout use cases (tell if you see something this won't cover!). It'll also enable new types of components that you can now attach not just markup, styles, and interactivity, but also bits of data. E.g. imagine a SEO component that queries standard data + you can pass in page specific data as well. Or a team member avatar component that has queried the name + image of the 10 team members so you can drop in the component anywhere it's needed. Or a product preview that you can manually add throughout the site as needed. On the last idea — something I've thought would be cool is a way to "stamp out" lots of similar components. There's now two ways to specify data requirements for a component. You can export a query "fragment" that you then mix-in to any page component query where you need the component and then take care of feeding the right data down to the sub-component. Which works well but requires some fiddly work each time you use the component. Or, you could now directly specify the query for the component. The downside is that the query is static so for the case of avatars or product details, you'd either have to query all product info you might use and pass in a prop to specify the specific one to render or create duplicate components. The later (creating lots of duplicate components) we could automate fairly easily. Imagine a component for product details. import React from 'react'
import { StaticQuery } from 'gatsby'
export default class ProductDetails extends React.Component {
render () {
<StaticQuery
query={`graphql
query ProductDetailsQuery($id: String!) {
product(id: { eq: $id }) {
title
price
description
}
}
`}
render={staticData => (
<div>...</div>
)}
/>
}
}We could then automatically stamp out identical components for each product ID — but crucially, we'd also extract out the actual component so that code wouldn't be duplicated. Then you could just import each product details component like Anyways, lots of details would need worked out there but wanted to toss it out as an idea as well. |
|
Some more evidence that removing our special layout components from v2 might be a good idea: |
|
The reason why people are asking that is because of what I wrote a couple
of posts up - defaults and preference order.
Most web app systems have defaults that are used if you don't override the
layouts. This is everyone right from Rails to Hugo. So the confusion is
stemming from - how do I get a different layout for this particular page
since Gatsby is not letting me import a layout component .
React is simpler - there are no defaults. So if you don't import stuff, you
don't get that available.
In general I think Gatsby is taking the approach of rails - to have
defaults available without explicit imports, however it doesn't mean we
can't override them.
What I'm concerned is that the graphql style of layout components won't
actually work - because it's not that layout templates/components take the
same data and render it differently. Templates would ask for different data
in different templates.
So when you think of templates, you should think both ui and data together.
…On Tue 17 Apr, 2018, 04:54 shannonbux, ***@***.***> wrote:
Some more evidence that removing our special layout components from v2
might be a good idea:
After running a 2-day Gatsby workshop last week, we heard this question
from several people: "Does Gatsby force a layout component to every page
without me having to import it?" They expected to have to import it, and
were confused that they did not, since standard React components would need
to be imported. @KyleAMathews <https://github.com/KyleAMathews>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3830 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEsU9tvIR-iZytPPQjVD2j1IpRH_Ytrks5tpSgXgaJpZM4R3wR8>
.
|
|
Thanks everyone for the great discussion here. This proposal was written up as RFC 0002 and implemented on the v2 branch in #4887. There will be an upgrade guide (#3986), until then you can see this change applied to some of the example sites on the v2 branch - look for the ones with Gatsby dependencies set to |
|
Hi, I've opened an issue regarding code splitting and i18n files and it seems using layouts could be the best solution, like suggested by @szimek I wonder if using something like that still works in v2 with the plugin: Because this is not really documented and let me think we can only use one global layout at the same time. @szimek have you migrated to v2? |
|
@slorber Yeah, we did. I don't remember where we found it, but we're using this HOC: // src/lib/i18n/withIntl.js
import React from 'react';
import { IntlProvider, addLocaleData } from 'react-intl';
import { localeData } from '../locales';
addLocaleData(localeData);
export default (ComposedComponent) => {
const withIntl = (props) => {
const { pageContext } = props;
const { locale } = pageContext;
// eslint-disable-next-line global-require, import/no-dynamic-require
const messages = require(`../../../../config/translations/${locale}.json`);
return (
<IntlProvider locale={locale} messages={messages}>
<ComposedComponent {...props} />
</IntlProvider>
);
};
return withIntl;
};Then we wrap each template in it: // src/templates/PostPage.js
import { injectIntl } from 'react-intl';
import withIntl from '../lib/i18n/withIntl';
function PostPage({ data, intl }) {...}
export default withIntl(injectIntl(PostPage));And use them in createPage({
path: `${pathPrefix}/posts/${slug}/`,
component: path.resolve('./src/templates/PostPage.js'),
context: {
locale,
postId,
},
}); |
|
Thanks @szimek With your code, particularly this line |
|
@slorber Unfortunately, you're right. After migrating to v2, we've started building the app separately for each language, so it's not really a big problem for us at the moment. However, ... Now that I really hoped we'll be able to use BTW. Have you tried |
and others
I've found that multiple layouts is a constant source of confusion. It's a really advanced feature that very few people need. It mostly causes confusion from people trying to use it but not understanding how to use it so wondering why extra layout components they add don't work.
It also causes problems because if a site has multiple layouts, there's no one "entry" for the entire site where you can import e.g. global css.
Also 99% of sites only need one global layout.
The 1% that do truly need multiple layouts can easily solve this with React. Just conditionally render different headers or footers. Also there's no performance problem with this as you can lazy load components needed for different sections of the site.
Removing multiple layouts support would also conveniently remove a lot of complicated code.
Has anyone used multiple layouts on a site and consider them essential to that project?
The text was updated successfully, but these errors were encountered: