[User Storage Service] browser client, React hooks, injection rendering #268312
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -99,6 +99,10 @@ export class InjectedMetadataService { | |
| getFeatureFlags: () => { | ||
| return this.state.featureFlags; | ||
| }, | ||
|
|
||
| getUserStorage: () => { | ||
| return this.state.userStorage; | ||
|
Member
Author
There was a problem hiding this comment. I believe this should be gated and consumers that need injection of their storage can opt into it. Somewhere in the storage integration, there should be a configuration to opt into injection when the consumer registers their storage type. This should be the case because there could be consumers that have a large payload, where we want to just request the storage item async always.
Contributor
There was a problem hiding this comment. I wonder if we should even inject the user storage information into the HTML that gets served to the user, I think doing so makes it such we can almost never cache the index HTML for an authenticated user on a CDN given it's content is dynamic, without adding this the dimensions for caching heuristics are well known.
Member
Author
There was a problem hiding this comment. I get what you're saying but the pattern of injecting metadata in server-side rendering has been in use for a long time. We already do this with feature flags and UI settings, theme info, etc. It's a useful technique when we need to apply stored values into the hot paths of rendering
Member
Author
There was a problem hiding this comment. I did an experiment to inspect the HTML that is delivered to see what is getting injected. It is the big chunk of data in this screenshot: 
Contributor
There was a problem hiding this comment. I'm aware we send along couple of these kind of configurations, however those configurations typically could be scoped to a set of users, but with the user storage addition the eventual generated entry point is now completely unique. This is not a blocker from my side, it's just something I want to confirm that we are sure we'd like to do especially that you mentioned consideration for an async approach.
Member
Author
There was a problem hiding this comment. Good point. I'd like to table this for now. The primary consumer of User Storage will be the project side navigation, using this to store a customized nav for each user / space. I see a risk that would hurt UX if we're not showing the nav to the user asap, because we have to fetch the data in nav plugin setup. I'll call out your point in the epic issue: https://github.com/elastic/kibana-team/issues/2874 |
||
| }, | ||
| }; | ||
| } | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.