Add inserter state to the Redux store?

[BE-Webdesign]

Should we add the state of the inserter to the Redux store? I think it would make it a lot easier to work with.

Since we have multiple inserters, a top and bottom etc., we would also want to probably reflect that in the store. If we add inserters mid block they can have a UID generated and then destroyed.

Potential state could look something like:

inserters: {
    "top": {
        isOpen: true,
        focusedBlockType: 'core/heading',
        blockTypes: [
            // Data from wp.blocks.getBlocks(),
        ],
        visibleBlockTypes: [
            // Filtered block types based off of searchValue.
        ],
        searchValue: 'tacos',
    },
    "bottom": {
        // Similar shape as above.
    }
}

[youknowriad]

Is this state useful outside the inserter instance itself? If not, I don't see any value in moving it to the Redux Store.

[BE-Webdesign]

Is this state useful outside the inserter instance itself?

Probably not.

In my experience, React works best when it doesn't worry about managing its own state. (To clarify, more when we as developers do not worry about managing React's state manually) When all state interactions are delegated out to Redux, React basically becomes a super fast rendering engine for the DOM; you can accomplish this incrementally as well. Redux can be useful for describing the state of everything and from that store the view can be built out. When working with GUIs, using Redux to basically become the Presenter for the ViewModel can be very powerful and makes testing extremely easy and fast.

We don't have to use Redux in this manner, but I would encourage at least giving it a try and seeing if everyone likes it or not. The value, to me, is less cluttered components, higher modularity, and better performance as every render has no extra logic which reduces the complexity of each render. When views become essentially stateless you are exponentially increasing the performance of a render, but React is already very fast so the gains can be trivial. The performance can also go negative with this approach if not done right, like not taking advantage of the component lifecycle methods, and many more gotchas.

[youknowriad]

I've seen this pattern "Redux everywhere" used by a lot of persons in the JS community. There are other persons advocating for more local state as well.

IMO it's a matter of balance, if you need a state to be shared by multiple components, go for redux but if not just stick with local state (Redux comes with its drawbacks: Boilerplate and less modularity.

higher modularity

I've seen this argument a lot but it's not really true. Assuming we separate the "container component" from the "presentation component", this, in a way makes the "presentation component" reusable but let's think about it more. What's more reusable?

• The presentation component: A UI of the inserter with a lot of props to be passed to fill this UI and handle the data logic
• The container component: A component that needs to be nested inside a Redux Provider to work (assuming the reducer of this store has the right shape)
• The standalone component: A component with local state, we can use in any place we want without any hassle or constraint.

better performance

Allow me to doubt this, remember that any dispatch rerenders all the connected components (at least the containers's selectors) which has a tendency to grow over time while a setState call rerenders the current component only.

[BE-Webdesign]

Allow me to doubt this, remember that any dispatch rerenders all the connected components (at least the containers's selectors) which has a tendency to grow over time while a setState call rerenders the current component only.

Yeah definitely, most of my benchmarks for when I switched to this style on my apps were probably against terrible implementations at the start, so my perception is most likely skewed. Maybe I will run some experiments on this repo and find out if it would improve anything performance wise. But most likely the performance gains could also be done purely in the component too.

I've seen this argument a lot but it's not really true. Assuming we separate the "container component" from the "presentation component", this, in a way makes the "presentation component" reusable but let's think about it more. What's more reusable?

The presentation component: A UI of the inserter with a lot of props to be passed to fill this UI and handle the data logic
The container component: A component that needs to be nested inside a Redux Provider to work (assuming the reducer of this store has the right shape)
The standalone component: A component with local state, we can use in any place we want without any hassle or constraint.

I agree a lot. Maybe I like over engineered stuff lol 😄.

IMO it's a matter of balance, if you need a state to be shared by multiple components, go for redux but if not just stick with local state (Redux comes with its drawbacks: Boilerplate and less modularity.

Sounds good, I will try and stick to this mantra in my contributions.

[BE-Webdesign]

Should we close this issue out as it goes against the idea below?

if you need a state to be shared by multiple components, go for redux but if not just stick with local state.

[BE-Webdesign]

We might need to have the state be accessible to other components for knowing if an inserter is currently open. So maybe that is the only state we would potentially want to add to the Redux Store.

[youknowriad]

We might need to have the state be accessible to other components for knowing if an inserter is currently open.

Yeah! Let's close this. I'm also thinking, we might need it when we'll tackle the inline inserter maybe. Let's keep our UI needs drive the way we handle this 👍