Fix/fix ssg ssr init

[DmytroHryshyn]

What does this PR do?

Fixes # (issue)

Requirement/Documentation

• If there is a requirement document, please, share it here.
• If there is ab UI/UX design document, please, share it here.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (refactoring code, technical debt, workflow improvements)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Tests (Unit/Integration/E2E or any other test)
• This change requires a documentation update

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Mandatory Tasks

• Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my PR needs changes to the documentation
• I haven't checked if my changes generate no new warnings
• I haven't added tests that prove my fix is effective or that my feature works
• I haven't checked if new and existing unit tests pass locally with my changes

[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 "Fix/fix ssg ssr init". 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]

it means that this page never needed the dehydrated state?

[DmytroHryshyn]

there is a difference between passing prop and dehydratedState
when we pass a dehydratedState or initialData to query, it does not run request on the client side and query status is success immediately. When we pass it as prop, query will run again on client side.
I intentionally did not use initialData here, because in some cases we need to run query one more time on the client side. (for instance for ssg pages when user has lang other than en)

[hbjORbj]

you will have merge conflict here. layout is deleted in main branch. I merged layout.tsx and page.tsx in a PR that was merged.

[grzpab]

what was the issue here?

[DmytroHryshyn]

we allow passing i18n as prop. other alternative is to pass it in dehydratedState, but in this case we will have to use createProxySSGHelpers which requires trpc router.

[github-actions]

This PR is being marked as stale due to inactivity.