Allow for separate t3 options on the server and client - #364
Open
lleicher-sg wants to merge 1 commit into
Open
Conversation
…tions on server and client
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Right now, it is not possible to use different options for typo3 on the server and client.
The nuxt-typo3 documentation describes the usage of a server-only url, but that seems to be incompatible with the
useT3Options()composable.Use Case
When hosting a Typo3 Headless + Nuxt app in Docker, it would be nice to use a "fast" URL towards the typo3 server to bypass potential reverse-proxies.
E.g. three containers "nginx", "nuxt" and "typo3". Is a reverse proxy handling SSL termination and redirects to nuxt or typo3, depending on the hostname.
If this described setup is tested locally, direct communication is even required when using entries in
/etc/hoststo 127.0.0.1...Problem
Currently, Nuxt SSR has to fetch using the "public" https url (the same as the client), because of the way the
useT3Options()composable is implemented:So any non-public runtime config is just ignored.
Additionally, the
useT3OptionsState()composable uses auseState()which transfers server configuration to the client via hydration.Proposal
The T3OptionsState should not be transferred to the client, but instead be rebuilt upon calling
useT3Options().This way, we can safely read from the non-public runtime config for SSR.
This PR does exactly that.
I am not sure if this covers all usages of
useT3Options()in the library itself.I've tested it in a project headless Typo3 project as drop-in replacement and it seems to be working just fine.
This could potentially introduce a breaking-change for projects using the
useT3OptionsState()directly.I think it would be better to support server-/client-sided-options to allow for more flexibility in hosting requirements.