INT-2095 Ensure initial props needed for each page are passed to PageWrapper

[hbjORbj]

Problem:

• children props are not being passed to PageWrapper. children.props in layout.tsx are always null somehow.
• we are nesting multiple PageWrappers inside the root PageWrapper (that exists in (layout)/layout.tsx or (no-layout)/layout.tsx. For instance, (layout)/insights/layout.tsx file has PageWrapper and this is passed to (layout)/layout.tsx which also has PageWrapper.

Solution:

• Implement the infrastructure ensuring that the initial props needed for a page are passed to PageWrapper
• A page that needs initial props to be properly rendered must have getProps function and export it
• The page has to specify its relative path as follows so that (layout)/layout.tsx or (no-layout)/layout.tsx can dynamically import its getProps function

export default function Insights(props: any) {
  props.params.relativePath = "insights/page.tsx";
  return <InsightsPage />;
}

• @DmytroHryshyn @grzpab If you agree with this approach, I can make this change in other pages in app router + add this improvement to our calcom boilerplate codemod

[linear]

INT-2095 Ensure initial props needed for each page are passed to PageWrapper

• Implement the infrastructure ensuring that the initial props needed for a page are passed to PageWrapper
• A page that needs initial props to be properly rendered must have getProps function and export it
• The page has to specify its relative path as follows so that (layout)/layout.tsx or (no-layout)/layout.tsx can dynamically import its getProps function

export default function Insights(props: any) {
  props.params.relativePath = "insights/page.tsx";
  return <InsightsPage />;
}

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

No release type found in pull request title "INT-2095 Ensure initial props needed for each page are passed to PageWrapper". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

[grzpab]

This solution is not statically analyzable, I am thinking if we could come up with something else. Could we initialize the PageWrapper outside of the layout files (as in, directly in the files that need them?)

[hbjORbj]

Superceded by #77