Documentation: Improve note for 'blockType.save' method #70942
Conversation
There was a problem hiding this comment.
I like the updates. Makes it more clear.
The one thing we may also want to call out though is that it won't just cause block validation issues. But also that it won't have the desired effect either. Using dynamic data doesn't mean that the block will actually display dynamic information.
When I used to give trainings / workshops it helped people when I explained that the save function was only there to generate a static string of HTML which gets saved to the database.
Because people often though that they could just write a react component there which would then render as react on the frontend. (Which arguably I still wish sometimes was how it worked 😅 just all in server components in WP 💀😅)
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
The top description already alludes to that IMO. I'm out of ideas and open to suggestions. iAPI also enables static save markup to become interactive. |
|
I'm going to land this. I'll create a follow-up if anything "clever" comes to mind regarding the non-dynamic nature of the |
What?
PR improves the note for the 'blockType.save' method, highlights its pure nature and improves restricted API examples.
Testing Instructions
None. Confirm that changes make sense.