As the requirements of the editor application have grown, our simplified state file structuring has become increasingly disorganized. We had initially chosen to group actions, effects, reducers, and selectors for all features. While this helped avoid a sprawl of files which can proliferate in Redux-based state folders, it did not help provide a clear picture for how data is structured or how changes flow through the store.

I believe we optimized on the wrong simplification: on concepts of reducers, actions, and selectors, rather than the functionality that a global state store serves to support.

Enter the "Ducks" pattern. In the Ducks approach, reducers and actions are colocated based on functionality. Where currently all reducers are defined in a single reducer.js file and actions in actions.js, in a Ducks approach each distinct feature would define both the reducer and actions in a standalone file.

Proposed Folder Structure

Before:

/actions.js
/reducer.js
/selectors.js
/effects.js

After:

/blocks.js
/selection.js
/notices.js

...where an individual feature file would contain:

// Reducer

export default function reducer( /* ... */ ) {
	// ...
}

// Action Creators

export function createNotice( /* ... */ ) {
	// ...
}

// Selectors

export function getNotices( /* ... */ ) {
	// ...
}

// Effects

export const effects = {
	// ...	
};

This provides a manageable pattern to scale, isolating behaviors of individual features, while retaining a minimal set of files. It lends clarity in that a developer who is interested in the state capabilities of notices needs only review a single file.

Proposed "Modules"

• Editor (Initialization, UI?)
• Post
• Preferences (User?)
• Blocks
• Selection
• Inserter
• Typing
• Notices

As a testiment to the benefit of modularizing, per #2761, isolating post logic would simplify an eventual split between a base editor and post-editing-specific behaviors.

Next Steps

I would suggest as part of this transition that we also create a new state directory within editor. Based on the anticipated number of changed files, it may be wise to tackle this as a standalone first step, before moving forward with splitting actions, effects, reducer, and selectors by feature.

Thoughts?