Manage block editor state and data
•Download as PPTX, PDF•
0 likes•1,225 views
Gutenberg’s data module looks intimidating at first, but under the hood, it’s simple and easy to work with. The data module is built upon the same core principles of Redux but has some of its own characteristics. It lets us manage and share data in a modular way. In this talk we’ll discuss it’s similarities to Redux, subscribing and dispatching events, creating custom stores and using custom reducers. We will also be looking at a few real-world problems and how we could solve those using the data API.
More Related Content
What's hot
What's hot (20)
Similar to Manage block editor state and data
Similar to Manage block editor state and data (20)
Recently uploaded
Recently uploaded (20)
Manage block editor state and data
- 1. Manage Block Editor State and Data Ravi Chandra Senior Web Engineer at 10up
- 3. wp.data Built upon the same core principles of Redux
- 4. What is Redux ? Redux is a popular JavaScript library for managing the state of your application
- 5. ● Actions ○ An action is a plain JavaScript object that describes what happened. It has a type property which describes the action and additional data/payload. The three building blocks of Redux ● Reducers ○ A function that takes current state and action as arguments, and returns the next state of the app ● Store ○ Store is a Javascript object which holds the whole state of the app
- 7. wp.data ● Wrapper around redux ● Also available as a standalone npm package @wordpress/data ● Methods ○ select ○ dispatch ○ Subscribe ● Has a registry which registers and maintains multiple stores
- 8. wp.data.select ● Requires the store name argument and returns all the selectors registered for that store. ○ E.g. wp.data.select(‘core/editor’) ● Default Gutenberg stores ○ core: WordPress Core Data ○ core/annotations: Annotations ○ core/blocks: Block Types Data ○ core/block-editor: The Block Editor’s Data ○ core/editor: The Post Editor’s Data ○ core/edit-post: The Editor’s UI Data ○ core/notices: Notices Data ○ core/nux: The NUX (New User Experience) Data ○ core/viewport: The Viewport Data
- 10. Get the current Post ID
- 11. Get the current Post object
- 12. Get the featured image ID
- 13. wp.data.dispatch ● Requires the store name argument and returns all the actions registered for that store. ○ E.g. wp.data.dispatch(‘core/editor’) ● Triggers an action which in turn goes through a reducer and updates the store.
- 14. Code Examples
- 15. Edit Post Title
- 16. Auto save Post
- 17. Save Post
- 18. wp.data.subscribe ● Subscribe to any change event to the state. ● Accepts a callback function which gets invoked when any value in the store changes. ● This is global and not specific to any store.
- 19. Subscribing to change events
- 21. Display a notice to the user if the title has more than 10 characters
- 24. Give Me a Challenge
- 25. ● Dynamically translate all blocks in a post. ● Translation API is expensive, so we want to limit the API calls. ● Add a “uuid” attribute to all the block types and set it as a unique value for each block when the block is added to the post. ● Based on the unique “uuid” value for each block we can store the translated value for that block in post_meta using the uuid as meta_key.
- 29. To
- 30. Custom Stores
- 31. wp.data.registerStore ● Add your own store to the centralized data registry ● Accepts two arguments ○ Name to identify the store. ○ Object with reducers, actions and selectors. ● After the store is registered, it can be accessed with wp.data.select( ‘store-name’ ) or wp.data.dispatch( ‘store-name’ ). ● Useful if you want to maintain a custom data store with your own actions and reducers. E.g. Custom plugin for the block-editor.
- 37. ● wp.data registry is not exposed globally, which makes it difficult to modify existing reducers. ● We can use `wp.data.use` to register a dummy plugin, the `use` method returns the registry. ○ The `use` method might be deprecated in a future release. ● Using the registry object we can access a specific store like `core/data` and replace existing reducers or add our own.
- 38. Replace the default “Post updated.” notice when a post is updated.
- 42. Resources ● https://gist.github.com/ravichdev/d467208b627e6de7b2aab185698c7 83f ● https://developer.wordpress.org/block-editor/packages/packages-data/ ● https://medium.com/javascript-in-plain-english/the-only-introduction-to- redux-and-react-redux-youll-ever-need-8ce5da9e53c6 ● https://stackoverflow.com/questions/48104778/how-does- reducereducers-work ● https://github.com/WordPress/gutenberg/tree/master/packages/data
- 43. Q&A
- 44. Thanks!
Editor's Notes
- I am Ravi, I am a Senior Web Engineer at 10up. I am going to share with you today the Gutenberg's data module and how to manage its state and data. Lets take a quick poll, Show of hands: How many of you are developers here ? How many of you here have developed a custom Gutenberg block ? How many of you have looked at the wp.data API and it’s various methods, I mean like really looked at it ? This talk is developer focused, and I would be showing some code examples. I hope that at least some of you who are interested in Gutenberg development will get some useful information. If you are already a pro at Gutenberg, I have couple of challenging use cases with solutions at the end that might interest you.
- If you are used to the classic WordPress editor and metaboxes, customizing Gutenberg looks intimidating at first. It might look like it's not very developer friendly. It can also be frustrating or at least challenging at times, having to learn a completely new thing when you are so used to the classic editor.
- Customizing Gutenberg is really easy, it has an awesome data module under the hood which lets you manage and share data, subscribe and trigger events. It's built upon the same core principles of Redux. OOO
- Redux 101: Let’s briefly talk about what redux is. OOO A state in Redux is a JavaScript object, where the internal state of the application is stored as its properties, e.g. which user is logged on, the title or content of a post or name and email of a user.
- OOO Action: A user logged in, post title is updated etc. Action has mainly 2 properties, the type which describes the action type and payload or data which contains data required by the action. OOO Reducers: Lets say after a user logs in we update `isLoggedIn` property in our state. Reducer is where we would do that. Reducer functions check for the action type and use the action data to update the store. OOO Store: Store is what holds the whole state of the app
- This is Redux in a nutshell We have the UI which subscribes to the store and listens for events whenever the state changes. From the UI we dispatch an action whenever we want to update the state of our application. The reducer checks for action types and performs the state updation. The store is a Javascript Object deep within the browser’s window object with restricted scope. We would not have direct access to it and need to use special methods called as selectors to read any specific data in the store.
- wp.data is a Javascript object available in the browser if Gutenberg editor is loaded. Using the wp.data module we could listen to any changes in the editor like title, post content, and perform a custom action like checking the content length and so on. OOO It’s a wrapper around redux and exposes some of the redux methods along with its own methods. OOO OOO Methods: Select to read data from the store Dispatch to dispatch a custom action Subscribe to subscribe to the store changes
- wp.data.select provides an easy way to access a store selectors and thereby read data/state from the store. OOO It requires the store key argument and returns an object with all the selectors registered for that store. OOO Gutenberg has default stores used by the editor. We would be focusing more on the core/editor store today in all our examples.
- Lets look at some code examples we all have been waiting for
- Returns the current post id.
- Returns the current post as a JavaScript object, also includes any registered custom meta.
- Returns the edited post attribute, defaults to the saved value if the attribute is not edited. getCurrentPostAttribute returns the current/saved attribute. There are so many selector methods available in all the data stores. Use Google Chrome console to log the selector object to see all the available methods.
- OOO OOO Use wp.data.dispatch to trigger actions. Gutenberg has a lot of actions included.
- Update the post title in the editor. editPost accepts an object with the values you want to update
- Trigger the post auto-save.
- Trigger the post save.
- OOO OOO OOO This callback will be triggered whenever state is changed in any of the registered stores.
- Lets see an example of subscribe, select and dispatch together
- Lets say this is what we want to build.
- Get the post current saved title In the subscribe callback, get the edited/updated title in the post editor Check if the title has since been changed, if it’s changed, set the default title to newTitle. If the title is more than 10 characters dispatch a notice to the editor If it’s less than 10 characters, we simply remove an existing notice. The default notice reducer checks if a notice with the provided id exists and if it does it removes it else it just ignores the action. Lets see what we built in action.
- So we looked at a basic example of using the wp.data module, let’s take a look at a challenging one.
- END To achieve this we need a way to assign a unique key to each block. The key should not change on subsequent post/block updates.
- We are using WP JS hooks `addFilter` method on the `blocks.registerBlockType` to filter the block attributes being registered. This filter would run for any block registered with the `registerBlockType` method. We are extending the attributes property by adding the uuid attribute with type string
- We have a wrapper method onPostUpdateSuccessListener which takes a listener argument (which is a method) and returns a function. We check if the post is not saving or is not auto saving and check if the save succeeded. If it passes all these conditions, it means that the post update was successful and we invoke the listener callback
- Here we are innvoking the subscrie method with our custom wrapper function and passing a function as it’s callback As we have seen in the last slide the callback will be invoked when the post save is succesful In our callback we get all the blocks inn the post, iterate through them and check if the block has a uuid attribute set. If it’s not set we keep track of the block clientID Then for each of the blocks with no uuid attribute we trigger the updateBlockAttributes method and set the uuid.
- That results in this paragraph block converted to this.
- So far we have looked at using WP default stores, let’s take a look at how we can register and use our own custom stores
- We aer setting default state. We have 2 custom actions here, addItem and removeItem. Each action returns an object with the type property which describes the action and additional data/payload. The action type is what we use in the reducer to check for specific action and perform our reducer function.
- We have a selector getItems here which takes the state, reads the items from the state and returns it.
- Finally we register our store using the wp.data.registerStore function, pass the store name and the oject with our actions, reducers and selectors In our reducer we have 2 case statements one to handle ADD and other to handle remove. The add reducer just adds the item to our state and thge remove filters out the item and thery removes it from the state.
- Code examples of how to add, remove and get items
- So we have all these reducers already defined in the wp.data module like the notices reducer or the core/editor reducers. Is there a way we can add our own reducer function ? Maybe we want to add an additional property to the state when a post is saved. Lets see how we can do that
- Register a dummy plugin with empty object and get access to the registry Get the defaultNoticeReducer Write our own custom reducer function which checks for the CREATE NONTICE action and also checks if the notice is is SAVE_POST_NOTICE_ID. This notice id is only for the Post Updated notice, we know that because we looked at the wp.data notice store action source code. Then we find the index of our notice and replace the content value of the notice and we make additional changes to return the expected state.
- ReduceReducers is a custom function which takes a list of reducers and combines them all into one so that each reducer is called sequentially for an action. We call the replaceReducer method which comes from Redux and pass our new reducer object which contains all the reducers.
- And this is the result. The post updated message is updated. Using this method we can customize a lot of default functionality within Gutenberg. Spend some time looking through all the actions and reducers in wp.data package.
- Some additional resources