gatsby-plugin-create-client-paths with nested folder/files?

[JaKXz]

Description

Hi! I'm using gatsby-plugin-create-client-paths with ['/account/*'] in the options and I'm wondering if the following file structure will/should work (using index files and nested files & folders):

pages/
  account/
    index.js
    home.js
    settings.js

Steps to reproduce

The implementation of account/index.js looks something like this:

export default function Account() {
  if (!isAuthenticated()) {
    login() //calls external auth service
    return <Loading />
  }

  return (
    <Layout>
      <Router> //import { Router } from "@reach/router"
        <Settings path="/account/settings/" /> //import Settings from "./settings"
        <Home path="/account/" /> //import Home from "./home"
      </Router>
    </Layout>
  )
}

Expected vs Actual result vs workaround

What happens with this setup is that the Home component is rendered immediately on loading the /account route, even if the isAuthenticated() check returns false (and should render the <Loading /> component).

Then, I changed the name of the pages/account/home.js to pages/account/homepage.js with the same pages/account/index.js and everything seems to be working as expected...

Environment

  System:
    OS: macOS 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 5.7.1 - /usr/local/bin/zsh
  Binaries:
    Node: 12.5.0 - /usr/local/bin/node
    Yarn: 1.17.0 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 75.0.3770.100
    Safari: 12.1.1
  npmPackages:
    gatsby: ^2.10.5 => 2.10.5
    gatsby-image: ^2.2.3 => 2.2.3
    gatsby-plugin-create-client-paths: ^2.1.1 => 2.1.1
    gatsby-plugin-manifest: ^2.2.0 => 2.2.0
    gatsby-plugin-offline: ^2.2.0 => 2.2.0
    gatsby-plugin-react-helmet: ^3.1.0 => 3.1.0
    gatsby-plugin-sharp: ^2.2.1 => 2.2.1
    gatsby-plugin-styled-components: ^3.1.0 => 3.1.0
    gatsby-source-filesystem: ^2.1.1 => 2.1.1
    gatsby-transformer-sharp: ^2.2.0 => 2.2.0

[vrgimael]

I am having the exact same problem and I've been going nuts trying to figure out what's going on - checked all the blames on git and nobody touched these files in a while but for some reason the routing is not working anymore.

Maybe the routing plugin got broken in some recent commit?

[vrgimael]

This is definitely one of the weirdest things I've seen with gatsby - I still have absolutely no idea what the hell is going on but I've done some investigation and maybe someone can help us out here

So... I've found that whenever the "gatsby-plugin-create-client-paths" is enabled, the index.js file of the paths in "prefixes" simply gets ignored and the first file organised by some order (seems alphabetical) gets loaded instead.

I created a file named a.js and simply imported/exported index.js as default from the same folder and it actually, surprisingly, works; somehow.

I have no idea why the hell it is ignoring the actual index.js file in there and what's going on, really, this is very weird.

Any thoughts would be appreciated

[wardpeet]

Hi @JaKXz!

Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 💜

[JaKXz]

Hi @wardpeet - here you go: https://github.com/JaKXz/gatsby-client-paths-issue

yarn
yarn start
open http://localhost:8000/account

[JaKXz]

@wardpeet Is there anything else you need from my response? Just wondering if that label is up to date.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JaKXz]

Still seeing this issue!

[McFlat]

When I do the authenticated tutorial in a new directory it all seems to work fine, with gatsby-plugin-create-client-paths and with having the snippet in gatsby-node.js file. But once I try to make my project use the exact code that works on a tutorial it doesn't work in my project.

Getting an error, see below:

(EnsureResources, ) TypeError: Cannot read property 'page' of undefined

Stack trace:
TypeError: Cannot read property 'page' of undefined
at Object.children (http://localhost:8000/commons.js:1444:2044)
at EnsureResources.render (http://localhost:8000/commons.js:978:323)
at EnsureResources.componentRender [as render] (http://localhost:8000/commons.js:52118:64)
at finishClassComponent (http://localhost:8000/commons.js:33412:31)
at updateClassComponent (http://localhost:8000/commons.js:33367:24)
at beginWork$1 (http://localhost:8000/commons.js:34878:16)
at beginWork$$1 (http://localhost:8000/commons.js:39566:14)
at performUnitOfWork (http://localhost:8000/commons.js:38581:12)
at workLoopSync (http://localhost:8000/commons.js:38558:22)
at renderRoot (http://localhost:8000/commons.js:38251:11)
at scheduleUpdateOnFiber (http://localhost:8000/commons.js:37792:22)
at scheduleRootUpdate (http://localhost:8000/commons.js:40692:3)
at updateContainerAtExpirationTime (http://localhost:8000/commons.js:40720:10)
at updateContainer (http://localhost:8000/commons.js:40809:10)
at http://localhost:8000/commons.js:41336:7
at unbatchedUpdates (http://localhost:8000/commons.js:38060:12)
at legacyRenderSubtreeIntoContainer (http://localhost:8000/commons.js:41335:5)
at render (http://localhost:8000/commons.js:41464:12)
at http://localhost:8000/commons.js:868:891

Spent two days on this so far, so frustrating!

Tried to use exact package versions and reinstalling node packages with yarn to no avail.

What I've noticed is that gatsby-node.js never runs and app.js doesn't run either, nothing printed to the log when I have console.log statements all over those files.

  System:
    OS: macOS Sierra 10.12.6
    CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.3.1 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Safari: 12.0.2
  npmPackages:
    gatsby: ^2.13.64 => 2.13.64
    gatsby-image: ^2.2.8 => 2.2.8
    gatsby-plugin-create-client-paths: ^2.1.3 => 2.1.3
    gatsby-plugin-feed: ^2.3.6 => 2.3.6
    gatsby-plugin-manifest: ^2.2.4 => 2.2.5
    gatsby-plugin-offline: ^2.2.4 => 2.2.6
    gatsby-plugin-postcss: ^2.1.2 => 2.1.3
    gatsby-plugin-purgecss: ^4.0.0 => 4.0.0
    gatsby-plugin-react-helmet: ^3.1.3 => 3.1.3
    gatsby-plugin-sass: ^2.1.4 => 2.1.8
    gatsby-plugin-sharp: ^2.2.11 => 2.2.11
    gatsby-plugin-sitemap: ^2.2.6 => 2.2.6
    gatsby-plugin-styled-components: ^3.1.2 => 3.1.2
    gatsby-remark-copy-linked-files: ^2.1.4 => 2.1.6
    gatsby-remark-images: ^3.1.8 => 3.1.11
    gatsby-source-filesystem: ^2.1.8 => 2.1.9
    gatsby-transformer-remark: ^2.6.12 => 2.6.14
    gatsby-transformer-sharp: ^2.2.5 => 2.2.6
  npmGlobalPackages:
    gatsby-cli: 2.7.28

[jonniebigodes]

@McFlat can you create a reproduction following these steps with your code so that it can be looked at?

[JaKXz]

@jonniebigodes is this repro helpful? https://github.com/JaKXz/gatsby-client-paths-issue

Is there anything else I could clarify? This issue shouldn't be stale

[jonniebigodes]

@JaKXz sorry for the late response. But i believe i have a solution for your issue.
Here are the steps i took to triage and solve your issue.

• Cloned the repo you provided.
• Installed the dependencies.
• Issued yarn start, opened a new browser window to http://localhost:8000/account and i'm presented with the following:
  
• Fiddled with the code trying to solve the problem. Then it hit me, i remembered that Jason Lengstorf and Christopher Biscardi did a stream involving that used this plugin, more precisely this.
• With that in mind it hit me. The problem exists in the configuration itself, i changed gatsby-config.js to the following:

{
      resolve: `gatsby-plugin-create-client-paths`,
      /* options: { prefixes: [`/account/*`] } */
      options: { prefixes: [`/account/index/*`] }

    },

• Issued gatsby clean, followed with yarn start, let the build complete and opened up a new browser window to http://localhost:8000/account and i'm presented with the following:
  
• Just to be sure i've issued gatsby build && gatsby serve to generate a production build and serve it by emulating a live production server and opened up a new browser window to http://localhost:9000/account/ and i'm presented with the following:
  

• Based on this and i'm speculating, based on my testing and meager knowledge of gatsby, is that you need to "point" the path to where the actual file where the client side router is housed and not to the folder itself. Because doing this it looks like that gatsby when is building and generating the pages will treat the pages inside the folder as they were normal pages and not pages that should be treated in client side. And it results in the behaviour you're experiencing.

  I know that my explanation might sound a bit weird to understand, and i'll leave it to someone more knowledgeable of the plugin and gatsby to elaborate on this topic.

Feel free to provide feedback so that we can close this issue, or continue to work on it until we find a suitable solution.
@McFlat if you don't mind creating a reproduction and share it i can go over it and see if we can solve your issue.

[LekoArts]

is that you need to "point" the path to where the actual file where the client side router is housed and not to the folder itself

Correct! You can also see this in the example: https://github.com/gatsbyjs/gatsby/tree/master/examples/client-only-paths

It points to the /* and hence the router lives in pages/index.js. If the path would be /app/* the router would need to live inside pages/app.js.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JaKXz]

This is not stale - but perhaps solved by updating the docs with @jonniebigodes comment? Is this meant to be the intended behaviour? The way I was using the plugin originally is what’s most intuitive to me.

Maybe the plugin should allow you to set paths with a glob? E.g. /account/**

[jonniebigodes]

@JaKXz if you're willing fork the repo, read the contribution guide, make the changes to the documentation, using my comment, submit a pull request and we can go from there. Sounds good?

[JaKXz]

I’d love to, but I don’t want to block someone else who has more cycles than me! I’m in the middle of our product launch season!

I also question (like I mentioned earlier) if that’s what the intended behaviour is. But thank you for the information.
On Sep 29, 2019, 10:26 -0400, jonniebigodes [e-mail], wrote:

@JaKXz if you're willing fork the repo, read the contribution guide, make the changes to the documentation, using my comment, submit a pull request and we can go from there. Sounds good?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jonniebigodes]

No problem, i'll leave it to you if you want to take up on it in the near future or if someone else wants to take it i don't mind. Also i'm not familiar with the plugin code but it could be that what's inteded when it was created, i'll leave it to someone more knowledgeable of the plugin and gatsby to follow up on this and possibly offer a more detailed explanation.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JaKXz]

Not stale - does anyone know what the intended behaviour is for this plugin?

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[JaKXz]

This issue should not be closed.

[JaKXz]

@marcysutton sorry to ping directly, but this issue probably shouldn't be closed until the docs are updated [and it is proven that this is the intended behaviour of the create-client-paths-plugin]. Just wanted to put it on your radar! Thanks.

[JaKXz]

This issue is still not stale and should not be closed.