Add useSetting hook

[philipp-spiess]

Inspired by Vova's #47864, this adds a new useSettings() hook to replace the existing SettingsCascadeProps prop drilling.

I decided to not replace all of the props drilling just yet to avoid a massive merge conflict when Vova's PR ships. I also really want to focus on cleaning up the app shell instead and I need this particularly for one use case: Cleaning up globbing which, as it turns out, is just a computed value from the setting instead.

With this new settings API in place, I want to start trimming the shared props mess in a follow-up PR. This will then already remove the needs to pass the settings cascade around naturally and we will end up with a few smaller issues instead of a high change of breaking things.

I've also marked the existing settings APIs (including access to the SettingsCascade object directly) as deprecated. useSettings() should be used when possible. I don't think we need to validate the settings in every caller manually. 😅

Test plan

• Add console.log(useSettings()) to a route
• See the settings resolve. Wow. Magic!

App preview:

• Web

Check out the client app preview documentation to learn more.

[sg-e2e-regression-test-bob]

Bundle size report 📦

Initial size	Total size	Async size	Modules
0.01% (+0.32 kb)	0.00% (+0.35 kb)	0.00% (+0.04 kb)	0.00% (0)

Look at the Statoscope report for a full comparison between the commits 0d1154a and acd88ab or learn more.

Open explanation

• Initial size is the size of the initial bundle (the one that is loaded when you open the page)
• Total size is the size of the initial bundle + all the async loaded chunks
• Async size is the size of all the async loaded chunks
• Modules is the number of modules in the initial bundle

[courier-new]

I've long awaited this. 😍 EAGERLY APPROVE. 👍👍👍👍

[vovakulikov]

@philipp-spiess Nice change, only one thought about \useExperimentalFeatures\ hook, at the moment, it works via zustand global store (not just a context), but this hook is related to your change because there is a two options now to get experimental settings (three actually if we count prop drilling)

Do you think we could (maybe as a follow-up) migrate \useExperimentalFeatures\ to the version where this hook uses your new useSetting hook internally (and doesn't use different approach with global zustand store)

[philipp-spiess]

@vovakulikov Yes, this would be great! Do you know why we have zustand there by any chance? I wonder if I miss something by just doing what I do here and hooking it up in the app root 😅

[valerybugakov]

Cleaning up globbing which, as it turns out, is just a computed value from the setting instead.

Lol, what? 😃

[valerybugakov]

Do you know why we have zustand there by any chance?

I got the same question when refactoring the root search query state observer. Maybe @fkling can chime in and share more context?

The only reason that comes to my mind based on my limited experience with this part of the codebase is that zustand gives us reactivity. Still, according to the number of setExperimentalFeaturesFromSettings calls, we do not change experimental settings after the app init phase, so there's not much value in keeping this data reactive.

[valerybugakov]

Seeing the prop drilling of the settings cascade gradually disappear will be so pleasant!

I decided to not replace all of the props drilling just yet
I also really want to focus on cleaning up the app shell instead

Love this line of reasoning! We can move faster if we prioritize migrations in the app shell and component under Storm routes (the first one will be the home page). Then we can gradually move route by route into the storm and refactor them incrementally. Sadly it wasn't possible with the react-router migration, but it should work without issues with our internal deprecated APIs!

[fkling]

Do you know why we have zustand there by any chance?

I got the same question when refactoring the root search query state observer. Maybe @fkling can chime in and share more context?

Mainly two reasons:

• There was a time where we had been very reluctant to introduce new React contexts. Maybe those times have passed?
• Because of how zustand works callers can pull out a subset of settings without getting re-rendered when the whole settings object changes. However if settings are not changing frequently (which I didn't consider back then) or considering that you navigate between pages anyway to change the settings then that's not really a problem.

I guess it should be relatively straightforward to simply change the internal implementation of useExperimentalFeatures.

[philipp-spiess]

Because of how zustand works callers can pull out a subset of settings without getting re-rendered when the whole settings object changes. However if settings are not changing frequently (which I didn't consider back then) or considering that you navigate between pages anyway to change the settings then that's not really a problem.

Oh, I see. Yeah this is something that the Context API doesn't allow (yet, but it doesn't seem a priority either). I know of one place only where we depend on setting for something inside the current page and that is when configuring IDE extensions but it's something that is done at most ones (every subsequent setting change is expected to happen from inside the settings page). I wonder if it would be cleaner if we would just require a browser refresh when settings change. We could get rid of a lot of settings based propagation code if we can consider it readonly and static 🤔

Anyway this is a discussion for a different day :)

[vdavid]

Oh wow, this seems life changing! Thank you! ❤️