Remove/restrict wp-init effect to encourage/enforce initial state to be supplied by PHP for SSR

[westonruter]

To circle back on my comment on Proposal: The Interactivity API – A better developer experience in building interactive blocks:

Also, in relation to both data-wp-effect and data-wp-init, it is proposed here that the code be executed whenever the “node is created”. This presumably means when it is created/parsed on the client, right? If so, this seems to be at odds with the SSR goals. If the referenced expressions are external JavaScript code, and if these expressions run at load time, then this means a lot of markup actually won’t be SSR’ed. Or is it the intention that all effects which run at initialization must have PHP implementations in addition to JavaScript ones? Otherwise, I think that data-wp-init should actually be excluded from the proposal, requiring that any such initialization logic be performed server-side.

To this @luisherranz replied:

I’m not opposed to leaving wp-init out of the initial version, as there’s nothing you can do with it that you cannot do with wp-effect, but it seemed more intuitive for some basic usages of wp-effect to have a non-reactive version.

I wanted to elaborate a bit more on the concern about the client-side init code mutating the state which causes some DOM update: in other words, for there to be a possibility that the initial state may not be SSR'ed. The lack of SSR endangers both CLS and INP.

Let's say that you have some element that should conditionally display after some date:

<div
	data-wp-interactive
	data-wp-context='{ "{{namespace}}": { "isOpen": false } }'
	data-wp-init="effects.{{namespace}}.setMyInitialState"
	data-wp-bind--hidden="!context.{{namespace}}.isOpen"
>
	<p style="font-size: 1000px">Hello 2024!!!!</p>
</div>

And your JS code contains:

// view.js
import { store } from "@wordpress/interactivity";
 
store({
  effects: {
    setMyInitialState: ({ context }) => {
      context.isOpen = (new Date()).getFullYear() >= 2024;
    },
  },
});

This would result in the element being hidden after the DOM has loaded, resulting in layout shift.

Instead, I think we should encourage as much as possible that such an initial state should be supplied by PHP. One way to achieve this would be to eliminate the wp-init effect entirely, or to make the supplied context read-only for this effect.

[luisherranz]

Restricting APIs to avoid bad UX is an interesting topic, although in this case, I'm not sure if it's actually feasible.

First, there are use cases where modifying the context when an element is created is useful. For example, the Navigation block stores a reference in the context that is used later to know when the focus has left the submenu/overlay.

Second, even if you remove wp-init or restrict context on the first render, there will be other alternatives. The example that you shared works in the exact same way with wp-effect or any other directive that runs in the scope of the component (more about that in this discussion):

data-wp-effect="effects.{{namespace}}.setMyInitialState"

So, shouldn't we address this anti-pattern with education rather than trying to restrict the API? The Interactivity API is designed to leverage the server, so that's what we should emphasize when we teach it:

<?php
$is2024 = date( 'Y' ) >= 2024;
?>

<div
	data-wp-interactive
	data-wp-context='{ "{{namespace}}": { "isOpen": <?php echo $is2024; ?> } }'
	data-wp-bind--hidden="!context.{{namespace}}.isOpen"
>
	<p style="font-size: 1000px">Hello 2024!!!!</p>
</div>

By the way, for reference, you can do the exact same thing in React, and it would also lead to the exact same bad UX:

const Comp = () => {
  const [isShown, setIsShown] = useState(false);

  useEffect(() => {
    setIsShown(new Date().getFullYear() >= 2024);
  }, []);

  return (
    <div hidden={!isShown}>
      <p style="font-size: 1000px">Hello 2024!!!!</p>
    </div>
  );
};

Let me know what you think 🙂

[westonruter]

First, there are use cases where modifying the context when an element is created is useful. For example, the Navigation block stores a reference in the context that is used later to know when the focus has left the submenu/overlay.

OK, so making the context readonly probably isn't right then, but then otherwise it could be that renders are disabled if context is mutated in wp-init.

Or if a render does happen here, and SCRIPT_DEBUG is enabled, there could be a console.warn() or something to educate the developer on how they should be using the server for the initial render.

[luisherranz]

Or if a render does happen here, and SCRIPT_DEBUG is enabled, there could be a console.warn() or something to educate the developer on how they should be using the server for the initial render.

I really like this one, and I think it will be easy to implement.

I've added it to the Roadmap and we can implement it once the SCRIPT_DEBUG PR is merged.