Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider state middleware injection as extensibility mechanism #692

Closed
aduth opened this issue May 5, 2017 · 3 comments
Closed

Consider state middleware injection as extensibility mechanism #692

aduth opened this issue May 5, 2017 · 3 comments
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor.

Comments

@aduth
Copy link
Member

aduth commented May 5, 2017

Related: #594

In #594, when a post draft finishes saving, we adjust the current browser URL to reflect the new post ID. While this is necessary in the context of the dedicated editor screen, this reduces the portability of the editor as these URL changes are not applicable outside this context. If we'd want to allow initializing an editor on other screens (e.g. front-end, Customizer), we might need to explore options for injecting context-specific middlewares. This could serve as a generic extensibility pattern for any side effects of state changes.

For the post save navigation example, this could look something like:

wp.editor.injectMiddleware( ( store ) => ( next ) => ( action ) => {
	const { type, isNew, post } = action;
	if ( 'REQUEST_POST_UPDATE_SUCCESS' === type ) {
		const [ baseUrl, query ] = window.location.href.split( '?' );
		const qs = parse( query || '' );
		const newUrl = baseUrl + '?' + stringify( {
			...qs,
			post_id: newPost.id,
		} );
		window.history.replaceState( {}, 'Post ' + newPost.id, newUrl );
	}

	return next( action );
} );

See also:

@aduth aduth added Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor. labels May 5, 2017
@dmsnell
Copy link
Member

dmsnell commented May 31, 2017

Check out automattic/notifications-panel and how we do this to integrate with automattic/wp-calypso

injecting the enhancers

default actions for iframe mode

custom integrations in Calypso

it's been working incredibly well, by the way

@gziolo
Copy link
Member

gziolo commented Dec 29, 2017

8 months passed and we still need it 😃 We had a major refactoring in the way we handle data, but middlewares still play an important role. We could explore whether hooks library would be a good fit here. We might inject additional middlewares using filters in here: https://github.com/WordPress/gutenberg/blob/master/editor/store/middlewares.js#L40. @youknowriad suggested to make in an internal API for start.

@gziolo gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Feb 1, 2018
@jeffpaul jeffpaul added this to the Feature Complete milestone Feb 8, 2018
@mtias mtias removed this from the Feature Complete milestone Apr 12, 2018
@mtias mtias closed this as completed Jun 19, 2018
@aduth
Copy link
Member Author

aduth commented Jun 19, 2018

This is superseded by new patterns with data module: Notably the subscribe and withSelect APIs, which allow a developer to observe for and react to changes over time: https://github.com/WordPress/gutenberg/blob/master/packages/data/README.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

5 participants