If I want to maintain a global state without slices, do I still have to use the createSlice fn?

[binarykitchen]

Hello - old Redux/Re-frame user here, still coming back here with a fun question ...

I, personally, prefer a single source of truth, to put all states in one global place.
Yet, to initialise the global state, I would have to use the createSlice function, which feels misleading.

Because a global state is not a slice. It's like saying, a universe consists of multiple universes? 😅

What I am after, is to initialise the global state based on React props of the root component.

[markerikson]

I'm kind of confused on the question :)

createSlice is designed to manage updates to a set of data. That could, in theory, be the entire RootState of your whole Redux store.

But, we have always taught users to break their Redux root state down into smaller pieces ("slices") based on the types of data. state.posts is managed by a posts reducer, state.users by a users reducer, etc:

• https://redux.js.org/style-guide/#structure-files-as-feature-folders-with-single-file-logic
• https://redux.js.org/usage/structuring-reducers/splitting-reducer-logic
• https://redux.js.org/tutorials/essentials/part-2-app-structure#redux-slices

It's not strictly required. But it's the same principle as any other code you write. You break down larger functions into smaller functions to make them easier to understand and maintain.

So, the standard pattern is one createSlice call per slice of state: createSlice({name: "users"}), createSlice({name: "posts"}), etc.

Again, if you want to do something different you can. This is perfectly legal:

const rootStateReducer = createSlice({name: "doesntMatterHere"})

const store = configureStore({reducer: rootStateReducer})

but now your root reducer is having to keep track of all the state nesting itself.

Beyond that: a Redux store is a "global source of truth" with "all the state in the same place". Slices are just a way to split the root reducer up into smaller functions.

[binarykitchen]

Ah, this helps. Thanks, @markerikson - may I ask two more questions:

1. Time machine functionality
   If you split states using slices, will this impact the time machine functionality and performance?

2. How to initialise root state with React props when it's a component, not an app?

I'm writing a new React component library (not an app). I'd like to initialise the root state with some of the React props without using hooks. Is that possible? For example:

export interface RecorderProps {
  ...
}

const VideomailRecorder = (props: RecorderProps) => {
 // Here, how can I set the props to the RTK root state?
 // I don't want to use effects, hooks or anything asynchonrously so that it won't render until the root state is set.

  return <h1>Hello</h1>;
};

You can predefine root state with ClojureScript for React using re-frame:
https://github.com/day8/re-frame/blob/master/docs/Loading-Initial-Data.md#cheating---synchronous-dispatch

(defn ^:export init []
  (re-frame/dispatch-sync [:initialise-db]) ; Dispatch sync to set up before rendering
  ;; ... then mount your React app ...
)

Do I wonder if something like that would be possible with Redux/RTK? I'd like to be able to initialise the root state synchronously before the first render function is called.

[markerikson]

The entire root state gets serialized over to the DevTools, so nothing different there. Like I said, in the end it's all one "root reducer" function anyway, it's just a question of how that logic gets split up for organizational purposes.

The setup example may not be easily feasible. In theory sure it's possible to import the store (or even read it from context) and dispatch an action even while rendering... but that's absolutely against the Rules of React for what a component is allowed to do while rendering. (Also, given how React and Redux work, it would probably result in a React error saying "can't update other components while this one is rendering".)

However, if you're trying to do an update before the first render of anything is called... sure, you could just do that in your app's index file:

// src/index.tsx

import { createRoot } from "react-dom/client"
import { Provider } from "react-redux"
import { store } from "./store"
import { App } from "./App"
import { someAction } from "./someSlice"

// synchronously dispatch an action while this module is being imported and executed
store.dispatch(someAction())

const root = createRoot(document.getElementById('root'))
root.render(
  <Provider store={store}>
    <App />
  </Provider>,
)

We've even got an example of this in the Redux Essentials tutorial (where we actually dispatch a thunk to start loading data immediately, just before rendering the app):

• https://redux.js.org/tutorials/essentials/part-5-async-logic#loading-users

[binarykitchen]

Thanks, @markerikson, we're getting there.

Unfortunately, I cannot synchronously dispatch in my case. It's not an app, but a component library. It comes with one React component for reuse in other applications.

How can I initialise the root store with React props? Calling store.dispatch(someAction()) inside a React component is probably not a good idea, goes against the rules of React, like you said.

Perhaps some loading state is needed? I'm not sure and wouldn't like that idea to add extra states when it only milliseconds until the next render.. Do you have component/library-based examples, not app examples, for that?

[markerikson]

If it has to be based on component props, then the right answer is an effect. That does mean it doesn't happen until after the component has rendered.

[binarykitchen]

Right, thought so. That's unfortunate and forces me to add an extra loading state when it's only about a few milliseconds until the next request animation frame kicks in.