feat(http): expose transferStateInterceptorFn in public api#53815
Closed
jsaguet wants to merge 1 commit intoangular:mainfrom
Closed
feat(http): expose transferStateInterceptorFn in public api#53815jsaguet wants to merge 1 commit intoangular:mainfrom
jsaguet wants to merge 1 commit intoangular:mainfrom
Conversation
jsaguet
force-pushed
the
feat/export-transfer-state-interceptor-fn
branch
from
9993d61 to
f2de9e6
Compare
dylhunn
added
the
area: common
jsaguet
force-pushed
the
feat/export-transfer-state-interceptor-fn
branch
from
f2de9e6 to
0eadaea
Compare
jsaguet
force-pushed
the
feat/export-transfer-state-interceptor-fn
branch
from
0eadaea to
4f0165f
Compare
jsaguet
force-pushed
the
feat/export-transfer-state-interceptor-fn
branch
2 times, most recently
from
d815d68 to
0bd25a1
Compare
Expose `transferStateInterceptorFn` in public api so that developers can use it where best suited in the interceptor chain. This is useful when different urls are used to access the same APIs between server and browser. By placing the interceptor before requests urls become different, the cached request can be reused on the client. Note on usage: `provideClientHydration` should be called with `withNoTransferCache` to disable the default cache interceptor which is the last one executed.
jsaguet
force-pushed
the
feat/export-transfer-state-interceptor-fn
branch
from
0bd25a1 to
b152462
Compare
Contributor
|
Just for context: there is also an alternative proposal described in #53702 (comment). |
Contributor
Author
|
Closed in favor of #55274 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
Expose
transferStateInterceptorFnin public api so that developers can use it where best suited in the interceptor chain. This is useful when different urls are used to access the same APIs between server and browser. By placing the interceptor before requests urls become different, the cached request can be reused on the client.Note on usage:
provideClientHydrationshould be called withwithNoTransferCacheto disable the default cache interceptor which is the last one executed.Fixes #53702
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Currently, it is not possible to use http transfer cache when urls used to access the different APIs differ between calls made from the server and the browser.
This is a common use case when server side rendering happens in a private network in large companies.
It is mainly done to reduce latency, avoiding network proxies and even SSL handshakes when using HTTP in the private network.
Since the
transferCacheInterceptorFnis always the last executed interceptor, urls will be different and therefore not reused on the client.Issue Number: #53702
What is the new behavior?
This PR exposes the
transferCacheInterceptorFnin the public API so that developers can provide it manually inprovideHttpClient()to be able to solve their specific use cases.By placing
transferCacheInterceptorFnat the right place in the interceptor chain (e.g. before server & browser urls differ), developers can make sure that the requests will be reused on the client during hydration.The behavior of
provideClientHydration()is kept exactly the same (disabling http transfer cache withwithNoHttpTransferCache()and using global options withwithHttpTransferCacheOptions().The idea is that good defaults are applied for classic use cases while providing some flexibility for more complex cases.
Does this PR introduce a breaking change?
Other information
I would like for this PR to serve as discussion regarding the best option to solve use cases mentionned in #53702