Normalize page.tsx / page-data.ts & related page queries, codebase decisions for consistency

[electricenjindevops]

The codebase has mixed styles (in my opinion from what I have seen) for when a page type uses a page-data.ts file to hold interfaces, query handlers, and related functions.

A clear example can be seen with how Home (default locale 'page.tsx') is treated versus how the blog/page.tsx page is treated. The blog page has an accompanying page-data.ts file, whereas the home page does not. Another example is the product template having a page-data file that has imported functions, whereas the account page does not.

If the codebase is not normalized, I wonder if documentation could be provided to define best practices, explain any decisions for differences, and to guide future contributors on what file structure is desired.

One thing to note is that page-data may or may not be the best choice here. It is worth considering what developers prefer, build times, weigh pros & cons for having a file specific to each page like this separately, and evaluate other options.

One follow up question on this would be "what if two pages use the same interface, query, and handler?"

• should this be duplicated, in two separate page-data.ts files, or should a shared import be used by both to so there are no duplicate definitions? Again, this may be something that can be defined in documentation for future contributors.

[jorgemoya]

Hey @electricenjindevops!

Great feedback! Thanks for diving deep and showing clear examples of what we can do to improve. Normalization is definitely high in our priority list so we will take this feedback and refactor if needed (we want the code to be as easy to follow as can be). We have already discussed providing some clear documentation on these scenarios specifically, so we will keep you posted on it.

One follow up question on this would be "what if two pages use the same interface, query, and handler?"

What we are trying to achieve is deduplicate requests, and keeping fragments (or queries) closer to the component that needs it. In this scenario, it could be as simple as having the components provide the fragments the page needs, and create a query out of it. Even if two pages request the same info, hopefully the fragments are clearly defined for each component and it should be no issue. Definitely something we can make more obvious by providing some guidance 😅 .

[deini]

@electricenjindevops thanks for the feedback!

I'll answer the why and then touch on some points of what we can do moving forward.

Why

As @jorgemoya mentioned, we try to write our fragments and queries as close to where they are being used (Fragment Colocation).

We try to avoid moving queries/fragments to their own files. However, as you can see in our blog page, both the page itself and generateMetadata require similar data. If we write a query for each that means we do two requests, the only way we can dedupe this request is by using react's cache and pass the same function. At that point we move it into page-data.ts and use cache there.

You can see something similar with client components such as this one where we need to define the fragment outside of the use client file. This is a Next limitation where RSC can only import client components from use client files and not arbitrary exports.

Moving Forward

Documentation, as you mentioned all these things need to be documented with our reasoning behind them. We can also move all page fragments to page-data.ts for all pages. The client component fragment colocation is a bit tricker.