-
-
Notifications
You must be signed in to change notification settings - Fork 424
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Tech] Remove the Global State #3827
base: main
Are you sure you want to change the base?
Conversation
We already have this available globally on `window`, so we don't need it in the context provider as well
This also simplifies the logic for setting languages, as the component setting it now only has to call `setLanguage` & everything will update on its own
I'd recommend turning on the "Hide whitespace" option in GitHub's diff view for this commit
Note that storing this as an object is not a good idea, since `useShallow` checks for equality with `Object.is` (so when updating `helpItems`, we'd have to create a new `help` object, which would also cause re-renders for components only using `addHelpItem` / `removeHelpItem`)
e4ff8a7
to
4adc7e6
Compare
This was definitely the biggest change yet. Most of it was just taking a `runner` everywhere (to build a key to index into the record) This still has one issue (the library isn't refreshed after a game install/update finishes), it'll be resolved by future commits. Still, this should be a noticeable speed boost
4adc7e6
to
407c18a
Compare
I've chosen to inherit from the `ExperimentalFeatures` interface here to make picking out the values from the state easier. Otherwise, you'd need something like this for each one: ``` const enableNewDesign = useGlobalState(useShallow((state) => state .experimentalFeatures.enableNewDesign)) ``` which is rather verbose
This being a global function living on `window` was unnecessary as far as I could tell, and we can just implement it with a normal function being auto-called if `theme` updates
e4cf1e3
to
6ed21d2
Compare
This also modifies `InstallModal` to live on the Root & render based on only `installModalOptions`, like our other modals/dialogs do
b66b436
to
a3d156c
Compare
We can just do this on the one component calling this function This also introduces a local `refreshing` state for the Wine Manager, as the global state's is intended as a library refresh state
…deloadedLibrary` Quite a big commit, but splitting this up further isn't possible
a3d156c
to
556962a
Compare
something seems to be wrong with the global state after uninstalling a game, when I try to close heroic it thinks it's still doing something and shows the there's no way to make these changes more gradually? I know I always say the same but it's really hard to review 100 files changing, this changes a lot around the whole app, it's impossible for us to test/QA everything properly a nice thing that I liked about zustand was that it would allow us to move things to zustand gradually in different PRs with more focused scope to focus the test instead of changing everything, I'm always scared of changing that much I understand the commits are more granular, but everything in a single PR would block all the changes that are working because of issues in other places |
Part of why I was so granular with these commits is so we can take only a part of them and merge those. I'll create a new PR with some of the "easy" changes here, if that's easier |
The GlobalState / ContextProvider is now replaced with a Zustand store, which improves the re-rendering issues dramatically
The commits here are quite bite-sized, so reviewing them one at a time is recommended. The commit messages also include details in case something was out of the ordinary when migrating that specific property
Known issues:
Use the following Checklist if you have changed something on the Backend or Frontend: