Allow loading.js files to accept the params and searchParams props similar to other page-specific files

[PlagueFPS]

Goals

1. Allow for dynamic UI based on URL params on the page level
2. Easier developer experience since you won't have to mark the file as "use client" and call useParams() or useSearchParams() to achieve this behavior
3. Keep page-specific files correlated by allowing them to read these props (e.g page.js, default.js)

Non-Goals

Background

This feature is needed because it's hard to believe it doesn't already. When you learn how the page.js and default.js file conventions work, they get rendered after the initial request which contains the URL so they can receive these props, but, so does loading.js so I expected it to be able to receive these props as well.

Currently, the way you have to get around this is by marking the file as "use client" and then using the usePathname() or useSearchParams() hooks to read those params. These are extra steps that shouldn't have to be taken, it also isn't ideal for a loading.js file to be a client component, for this use case the loading.js file being a client component should be completely unnecessary and causes for unnecessary hydration when it should be able to read these params by default.

Proposal

Allow loading.js file to accept params and searchParams

[Dragate]

The primary benefit of loading.js is to provide immediate feedback to the user, creating the illusion of a fast-loading page even if the actual content is still being fetched. loading.js needs to be lightweight and quick to render, which I assume is static and thus, prepared at build time. I doubt that it can know what values params or searchParams might have at that time. Introducing dynamic URL parameters will potentially slow down the rendering, negating the benefit of having a loading.js file in the first place.

I would look into Suspense though. It does seem that you could pass page's params/searchParams as props to fallback components.