#Slot default to loading page defined further up the page hierarchy

25 messages · Page 1 of 1 (latest)

viscid relic
#

My current app structrue is:

app
│   not-found.tsx
└───form
    │   loading.tsx (A)
    ├───@header
    │   │   default.tsx
    │   │   loading.tsx (B)
    │   └───active
    │           loading.tsx (C)
    │           page.tsx
    ├───active
    │       loading.tsx (A)
    │       page.tsx
    ├───begin
    │       page.tsx
    └───complete
            page.tsx

The header slot is, of course, a header shown at the top of the page. It has 2 variants, a BaseHeader, which has a drop down to change the language, and then a FormHeader which is the main header for the form and includes a progress bar and nav bar. The FormHeader also has 2 variants of its own, loading and loaded specified by a state prop. This (wip) adds skeletons in place of the text in the nav bar.
The loading.tsx version A just displays a loading spinner. Version B displays the BaseHeader while loading, and version C displays the FormHeader with state="loading".
I would expect, according to the next documentation, for either header to be shown in its loading state as the slot would refer to the loading.tsx closest to it. However, it instead refers to the loading.tsx of /form and displays a loading spinner in place of the header. My first question is, am I expecting behaviour that's actually incorrect? Or am I doing something wrong?

The next thing I noticed on a similar topic is that by navigating to the 404 page, which includes a link back to the beginning of the form:

<Link href="/form/begin" className="underline">
    Return To Form
</Link>

and then clicking this link, it will take me back but it won't load the css module for the header. There are no 40x/50x errors in the network tab, it just doesn't even try to load the css. Refreshing fixes it.
I have a feeling this is related, and so I'm also wondering, what could be cauing this?

thin pivotBOT
#
Post created!

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

bright anvil
#

Hey @viscid relic - that sounds like a frustrating issue with the loading.tsxs. It's hard to know without seeing the code, so if you're happy to share, that'd be great. In general, I would probably remove (or rename) all of the loading.tsx files and bring them back one by one and see what works and what doesn't. Maybe you're missing an export statement in one of the loading components?

viscid relic
#

let me try removing them one by one and then adding them back and seeing what happens. I don't quite have the time now but later I can try and make a mininal example to reproduce, hoping its not an issue unique to this project. when I make that, is there anything in particular of this code you would want to see?

bright anvil
#

It seems the issue is mainly around form/loading.tsx and form/@header/*. That'd probably help 😁

viscid relic
#

i just tried removing them all and adding them back one by one. I did it in the order of C, B, active/A then A. everything was working correctly up until I added the last root loading.tsx. once that was active, it started using that instead of the other loading.tsx's and also failing to load the css after navigating back from 404.

bright anvil
#

Can you share the loading.tsx that failed?

viscid relic
# bright anvil Can you share the `loading.tsx` that failed?

the root loading.tsx thats casuing the is just

import LoadingScreen from "@/components/Loading";

const Loading = () => {
    return <LoadingScreen />;
};

export default Loading;

where LoadingScreen is essentially a div that contains an svg loading spinner and some text.

bright anvil
#

And what else is in @/components/Loading?

#

There are no imports or anything in that?

viscid relic
#

the TwStyles are just utility types

#

im going to attempt to make a mininal example and see if i can reproduce the issue

bright anvil
#

Yeah, I get the feeling it's a deep rabbit hole. I was about to suggest a similar "start again" approach and take one step at a time until you can see the line of code that breaks it. Sorry I'm not much help remotely.

viscid relic
#

@bright anvil if you go to app/form/loading.tsx and follow the comment hopefully you can see the issue happen too

bright anvil
#

Cool - I'll check that out now!

bright anvil
#

Okay, I think it's because of the redirect from /form to /form/begin. I moved app/form/loading.tsx to app/form/begin/loading.tsx and it's working as (I think) it's intended.

I also tried changing the content of the 404 page to link to /form instead of /form/begin. and that also works.

I don't know why Next isn't pulling the parent loading.tsx when you go from 404 back to the /begin URL, but perhaps it's something to do with the way the redirect from /form to /form/begin is handled internally?

viscid relic
bright anvil
#

I'm purely guessing, as I'm just another developer using Next.js 😁 But yeah, maybe. I'm thinking, when /form is hit, Next.js sees the loading.tsx and then redirects to /form/begin and uses that loading file it saw. If you go directly to /form/begin from the 404, then maybe it remembers it had a loading.tsx in the same directory (getting confused by the previous redirect)? Total conjecture, but hopefully my suggestion solves your issue...

viscid relic
bright anvil
#

If you have time - there's a chance that it is an overlooked bug as opposed to something we were overlooking.

#

I'm glad it works for you now though 🎉

viscid relic