Develop Reference

Redux + combineReducer, how can I update another reducer's key?

The React framework I'm using uses combineReducer internally. In the reducer I'm writing, I need to be able to update the state normally handled by a reducer in another key. Does Redux have an escape hatch that allows me to do this from within the reducer?

Can state be named differently (with another name like 'globalState') in ReactJS?

I am new to React (just 1 online course) and am discovering the magic of props and state. I realise that props are immutable and state is mutable. I am getting clearer about their uses but there's one point I would like to clarify that I have not been able to find online.
So props can be passed from Parent to Child and when they are passed the name of the variable holding the props can be changed. When state or its values are passed to child components, a mechanism is also passed along to the child to be able to modify the state at the parent level by the child.
I hope this is correct as so far this is what I have understood about props and state.
Now I have a project where I have "App.js" which is the topmost parent with "Home.js" as its child. I plan to use state in both of them. But the state in App.js is something of a global state (and I don't want to use redux) and the state in Home.js would be the state that the application would use for its regular use.
Now both of them are being named using the state={} format (I am using class based components) and referred to as this.state but within their own components, which is working fine.
My question is about the format of naming state as state, is this mandatory or just a standard that developers are expected to follow?
I've tried to change the name of the state and it seemed to work but maybe I did something wrong as I didn't really expect it to work... so that's why I wanted to confirm if it's ok to change the name of state in a component to something like globalState or store
Any advise would be appreciated.

When writing Class Components, you can only update the state using the setState method and it will write the state to the state property.
While I suppose you could add a globalState getter property to the class which returns the value of state, this seems pointless.
Note that storing data in other properties instead of using setState to write to it will not trigger a re-render. You're just writing to a property on the object and not dealing in anything that React considers state.
When writing Function Components, state is handled with the useState hook and the processing of storing the state data is handled by React internals. The state value is then assigned to whatever variable you want to assign it to after reading the returned state array.
const [anyName, setAnyName] = useState(defaultValue);
const [anyOtherName, setAnyOtherName] = useState(otherDefaultValue);

How can I dynamically inject a stylesheet in React without the website flickering/reloading?

I have a React application (next.js) that receives a stylesheet from a GET request and then appends it to the webpage.
When I load in the stylesheet the elements that are affected by that stylesheet rerender even if they are not changed. For example the stylesheet includes global styling to h1 tags, however the styling does not differ from the current styling yet it still re-renders.
Is there a way I can prevent this re-render/flicker/reload so that I can provide the user a seamless browsing experience?

Try to use reselect.
It supports memoization and I think this is what you are looking for.
React uses shallow compare to compare objects. When an app downloads new data from server, it receives a new object with styles data. React compares it with current props. Even if this object has the same data, for React it is going to be a new a object, so it decides to re-render the component.
Using reselect we are saving last object, that we received before and compare it with the new one. If the new object has exactly the same structure, reselect will send the old object (memoized object) to the component. This way the component will receive the same object and it will not be re-rendered.
Usually reselect is used with Redux, but according their FAQ it can be used independently:
Q: Can I use Reselect without Redux? A: Yes. Reselect has no dependencies on any other package, so although it was designed to be
used with Redux it can be used independently. It is currently being
used successfully in traditional Flux apps

Is the state returned from the useReducer Hook a "deep copy" or a reference of a reducers output?

I'm currently implementing global state handling in React using the Context API in combination with the useReducer hook.
I have two concerns regarding mutability:
When updating state in my reducers, do I need to e.g use Lodash's cloneDeep function to sever the reference between the objects going into my reducer and the stored state?
Is it possible to ruin the global state by manually mutating it outside reducers, or will it behave like "normal React state" in the sense that manual mutations will get overwritten during the next update cycle?
For reference: docs

Both useState and useReducer give you the exact value reference that you saved (either by calling someSetter(newValue), or returning a value from the reducer function).
In either case, manually mutating the value is wrong. In particular, both of them will bail out of updates if you return the identical reference as last time, so you should always update values immutably.

I would give this a read.
https://kentcdodds.com/blog/how-to-use-react-context-effectively
This is a really good guide of how to use react context in conjunction with useReducer the right way.
Let me know if it helps.

What is the simpliest way to write data to store in React-redux?

I'm using React and Redux (and also Redux-thunk for async tasks) in my app. So, when I need to write some data to store as a result of component interaction, I use both action and reducer for this. But is it always necessary? Especially in the situations when there are no connects to the modified field in components? Do I always need action and reducer to write some data to store? Or, maybe, there's a method like setState in store?

Yes, it is necessary to write a action and a corresponding reducer to that action.
This is because Redux is built based on the Flux architecture. Flux architecture uses actions and reducers to modify a particular state in the state tree. So, it is required and you can't skip it.
If you feel this is too much of boilerplate code, you should try mobx

there are two ways of storing the data in React with Redux environment
storing in component state - if data is only need for the component display or if it doesn't affect anything else in the app, like if you have multi-tab form then storing the current active tab. such data should be stored in component state
Storing in redux - any data which you want to access through multiple component or data which need to be present even if component unmounts should be stored in redux.
Now coming to your question, yes to manipulate redux store you need action, reducer. however if you perform some common tasks in most of the reducer you can take it out and create one common reducer, in my case we use common reducer to manipulate dropdown data, loading state, changing a specific object ( you can use "reducerdata" as key in various reducers to store Class Object required for the reducer and write common reducer to change its value)