Skip to content

Interactivity API: Add support for lazy-loaded derived state props #9673

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 12 commits into from
Closed

Interactivity API: Add support for lazy-loaded derived state props #9673

wants to merge 12 commits into from

Conversation

@DAreRodz
Copy link

@DAreRodz DAreRodz commented Aug 29, 2025 •
edited
Loading

This PR handles the server-side part to add support for "lazy" derived state props. From the trac ticket description:

There is a problem with derived state props when the store containing them is not loaded before hydration, which can happen with stores loaded asynchronously, e.g., @wordpress/interactivity-router, and also they have a PHP equivalent used for server-side rendering.

In that case, when those missing derived state props are evaluated, they will return undefined, and the directives subscribed to that value will replace the value generated on the server with the PHP function with undefined, effectively removing the HTML generated on the server.

The Interactivity API should be aware of which values were generated on the server via a PHP Closure (derived state props) and avoid replacing the directive's value on the client until a getter is available that can correctly recalculate it.

The way it works is by informing the iAPI runtime which Closures have been evaluated on the server, and serializing their paths into a data structure that is serialized along with the initial state and configuration.

There's also a special case with the data-wp-each-child directive. I should know if the corresponding parent data-wp-each directive is using a derived state prop to render the list. For nested data-wp-each directives, the value assigned in data-wp-each-child elements is the one of the top-most data-wp-each directive.

Trac ticket: https://core.trac.wordpress.org/ticket/63898

Related Gutenberg issue: WordPress/gutenberg#70872
Related Gutenberg PR: WordPress/gutenberg#71125

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions
Copy link

github-actions bot commented Aug 29, 2025

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • The Plugin and Theme Directories cannot be accessed within Playground.
  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

@DAreRodz DAreRodz mentioned this pull request Aug 29, 2025
Merged
@DAreRodz DAreRodz changed the title Iapi lazy loaded derived state props iAPI: Add support for lazy-loaded derived state props Aug 29, 2025
@DAreRodz DAreRodz changed the title iAPI: Add support for lazy-loaded derived state props Interactivity API: Add support for lazy-loaded derived state props Aug 29, 2025
@DAreRodz DAreRodz mentioned this pull request Aug 29, 2025
Closed
2 tasks
@DAreRodz DAreRodz marked this pull request as ready for review September 8, 2025 11:19
@github-actions
Copy link

github-actions bot commented Sep 8, 2025 •
edited
Loading

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props darerodz, luisherranz.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

luisherranz
luisherranz approved these changes Oct 17, 2025
View reviewed changes
Copy link
Member

@luisherranz luisherranz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM David! 🎉

My only thought is if maybe we should rename derivedStatePropsAccessed to derivedStateClosures so it's more explicit that it is related to closures only? What do you think?

@DAreRodz
Copy link
Author

DAreRodz commented Oct 17, 2025 •
edited
Loading

My only thought is if maybe we should rename derivedStatePropsAccessed to derivedStateClosures so it's more explicit that it is related to closures only?

Naming is hard. 😅

We can agree that using the term "derived state" is fine, as we use it extensively in the documentation. Regarding "props accessed" vs. "closures", maybe the "closure" part is implicit already in "derived state"? Only those properties are defined using closures. And I added the term "accessed" to indicate that these derived state props were accessed during server-side processing.

I know the term is a bit long, and I don't mind changing it to derivedStateClosures. Just sharing my reasoning. 😄

EDIT: What about accessedDerivedState or invokedDerivedState?

@luisherranz
Copy link
Member

luisherranz commented Oct 17, 2025

My thinking is that not all derived state needs to be tracked, only the derived state that is defined as closures in the server. There's derived state that is still "accessed" but it's value in the server is static.

@DAreRodz
Copy link
Author

DAreRodz commented Oct 17, 2025

My thinking is that not all derived state needs to be tracked, only the derived state that is defined as closures in the server. There's derived state that is still "accessed" but it's value in the server is static.

Makes sense. I just changed the name to derivedStateClosures. @luisherranz, feel free to commit the changes!

@luisherranz
Copy link
Member

luisherranz commented Oct 17, 2025

Can you change the $this->derived_state_props_accessed property to $this->derived_state_closures as well?

@github-actions
Copy link

github-actions bot commented Oct 17, 2025

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 60953
GitHub commit: c309f28

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

@github-actions github-actions bot closed this Oct 17, 2025
@luisherranz
Copy link
Member

luisherranz commented Oct 17, 2025

Thanks @DAreRodz!

Committed in c309f28 (r60953).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@luisherranz luisherranz luisherranz approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@DAreRodz @luisherranz