Provide a simple data layer for block developers

[iandunn]

Is your feature request related to a problem? Please describe.
Redux is painful.

It may be a great choice for building a complex app like Calypso or Gutenberg, but it seems like complicated, verbose overkill for 90% of block development.

Describe the solution you'd like

What do people think about some kind of alternative interface that simplifies things. Here's a rough idea of the kind of interface I'm imagining:

const { fetch, update } = wp.data;

class TodoApp extends Component {
	render() {
		return (
			<TodoItems
				items={ fetch( 'todoapp', 'items' ) }
				// ^ makes HTTP GET request to `wp-json/todoapp/items/`
			/>
		);
	}
}

class TodoItems extends Component {
	handleDelete( item ) {
		update( 'todoapp', 'items', {
			action: 'delete',
			id: item.id
		} );
		// ^ Makes HTTP DELETE request to `wp-json/todoapp/items/{item.id}`,
		// then waits for response, then triggers re-render() of TodoItems with updated `items` prop
	}

	render() {
		const { items } = this.props;

		return (
			<Fragment>
				{ items.map( item => {
					return (
						<Item onDelete={ item => { this.handleDelete( item ) } } />
					);
				} ) }
			</Fragment>
		);
	}
}

I'm sure there's lots of details to think through, and maybe some reasons why something like that isn't possible, but it feels like it's worth exploring, since it would greatly improve one of the most painful parts of block development today.

And of course, devs who want/need the full Redux feature set could still continue using the current abstraction layer.

[gziolo]

See #15473 where simplified API leveraging React hooks is being discussed and explored in referenced PRs. It's much closer to what you proposed but operates within constraints that React enforces. Should we close this PR in favor on #15473?

[nerrad]

See also #15737 which will hopefully land sometime next week and introduces the useSelect hook. For the fetches in your first example you could use a custom store for the fetch via something like this:

const TodoApp = ( props ) => {
	// props.appStarted is just an arbitrary prop I came up with to demonstrate
	// the dependencies argument here. Dependencies area a way of saying "Don't
	// call this again unless this prop has changed".  However items would still get 
        // updated automatically once `getItems` is resolved.
	const items = useSelect( (
		( select ) => {
                     // store selector is attached to a resolver that makes the fetch GET
                     // request to retrieve items.
		    return select( 'custom/store' ).getItems();
		}
	), [ props.appStarted ] );
	return <TodoItems items={ items } />;
};

I realize that the wp.data api can be intimidating, it was to me too when I first started diving into GB but there's a lot of stuff it takes care of that I've found makes working with side-effects and api requests much easier. For complicated state and extensibility it's needed.

[nerrad]

I'm going to close this issue because it is unlikely we will introduce a different api for working with data as described here. The important comment I see in here is this:

What do people think about some kind of alternative interface that simplifies things.

I think we are working towards that with #15473 (with #15737 being the first chunk). More general api changes fall under that work. The examples given here for a simpler interface are hard to extrapolate into a generic api that covers all potential use-cases and explorations would likely lead to the solutions already existent (or being worked on) in the ecosystem.