To consider:

• If the selectors are expected to return an array, the implementation will need to be revised to account for missing keys in the blockStyles state. Optionally, if it's necessary to distinguish between registered/non-registered, this will need to be considered (i.e. returns undefined for non-registered block, [] for registered block with no styles). It should probably be aligned to whatever the current behavior is, but if there's room for improvement here, elsewhere we've generally tried to use null as a value in these sorts of tri-state results ("unknown" null vs. "known, and empty" [])
• Moving this to selectors means we have to be more wary about returning a consistent value on subsequent calls. Elsewhere, we use a common reference to an empty array, or we could memoize the function.

• If the selectors are expected to return an array, the implementation will need to be revised to account for missing keys in the blockStyles state. Optionally, if it's necessary to distinguish between registered/non-registered, this will need to be considered (i.e. returns undefined for non-registered block, [] for registered block with no styles). It should probably be aligned to whatever the current behavior is, but if there's room for improvement here, elsewhere we've generally tried to use null as a value in these sorts of tri-state results ("unknown" null vs. "known, and empty" [])

I opted for:

• undefined when the block is not registered (to make it backward compatible)
• an empty array when no styles/patterns found

I can update to null if you think it is what we want to use from now on.

• Moving this to selectors means we have to be more wary about returning a consistent value on subsequent calls. Elsewhere, we use a common reference to an empty array, or we could memoize the function.

I opted for using createSelector as we need to merge two arrays from now on.

• an empty array when no styles/patterns found

I can update to null if you think it is what we want to use from now on.

To clarify, I only think null is appropriate as a value when a fetch is still pending, so it can't be known whether there is or isn't any results.

If we know one way or the other, we should return that known value. For what you describe, it seems like an empty array would be appropriate.

• Moving this to selectors means we have to be more wary about returning a consistent value on subsequent calls. Elsewhere, we use a common reference to an empty array, or we could memoize the function.

I opted for using createSelector as we need to merge two arrays from now on.

Hmm, I wonder if this is really worthwhile then. Any time we can simply point to a reducer value, it's always going to be more optimal than trying to compute a derived result, even if that result is memoized.

I dunno if there might be a middle-ground option here where we still have a ADD_BLOCK_TYPES case in these reducers, but we only store values if patterns exist. Then the selector can infer based on whether a block type is registered and it has a key in blockStyles state, what value to return.

Roughly:

function getBlockStyles( state, blockName ) {
    if ( state.blockTypes[ blockName ] ) {
        return state.blockStyles[ blockName ] || EMPTY_ARRAY;
    }
}

Otherwise, maybe we should keep it as is it is.

I dunno if there might be a middle-ground option here where we still have a ADD_BLOCK_TYPES case in these reducers, but we only store values if patterns exist. Then the selector can infer based on whether a block type is registered and it has a key in blockStyles state, what value to return.

The challenge with ADD_BLOCK_TYPES is that it has also a corresponding REMOVE_BLOCK_TYPES which is not handled in the original implementation and probably would be very difficult to handle as is. It doesn't look like we are close to finding a clearly better approach to handle this reducer. I'm inclined to keep it as is.

I'm closing this PR based on the feedback received. Thank you @youknowriad and @aduth for help.