Pattern to trigger one callback per page when some block is present #52514

luisherranz · 2023-07-11T15:16:22Z

luisherranz
Jul 11, 2023
Maintainer

Sometimes, blocks need to do something global on a page.

Imagine a block that needs to run some util from an external library. If only one block is included in the page, we could get away with data-wp-init:

<div class="wp-block-my-block" data-wp-init="init.namespace.runLibrary">
  ...
</div>

import { library } from "external-library";

store({
  init: {
    namespace: {
      runLibrary: ({ state }) => {
        library(state.namespace.someValue);
      },
    },
  },
});

But if multiple blocks are included, the data-wp-init will be run multiple times.

We could add some initialization flag, like this:

let init = false;

store({
  init: {
    namespace: {
      runLibrary: ({ state }) => {
        if (!init) {
          library(state.namespace.someValue);
          init = true;
        }
      },
    },
  },
});

But it's not very clean and we will include data-wp-init in the HTML more times than necessary.

One idea that we have is to let store initialization be a function:

store(({ state }) => {
  // Init.
  library(state.namespace.someValue);

  return {
    actions: {
      /* ... */
    },
    /* ... */
  };
});

It's not bad, although in this case, state may not be fully initialized if someValue comes from another store() call, so people would need to be careful about that, and it might force us into introducing some sort of priority system for the store() calls.

Also, there may be a case where this function needs to be run, not only by one block but by many blocks. In that case, I guess all the blocks should import the same JavaScript file that does a call to store() to initialize the external library.

Another idea could be to let blocks add a data-wp-init directive to the body, for example:

<body data-wp-init--run-library="init.namespace.runLibrary">
  ...
</body>

With a PHP API like this:

wp_add_body_directive( 'data-wp-init--run-library', 'init.namespace.runLibrary' );

Any other ideas?

DAreRodz · 2023-07-11T18:07:01Z

DAreRodz
Jul 11, 2023
Collaborator

Back in the "old days", for that kind of initialization, we had in Frontity some lifecycle initialization actions: init, beforeCSR, afterCSR, etc.

They helped packages do their stuff in different moments of the Frontity set-up. And it is pretty much what we want to do here, am I right? 😄

So, we could use that approach here as well, e.g.:

store({
  actions: {
    namespace: {
      // This special action could run after the store is ready.
      init: ({ state }) => {
        library(state.namespace.someValue);
      },
    },
  },
});

Another thing I have in mind (and I prefer) is to add a second argument to the store function, where you can define these kinds of callbacks, e.g.,

store(
  {
    state: {
      namespace: { /* &c. */ },
    },
  },
  // Optional object with callback definitions.
  {
    init: ({ state }) => {
      library(state.namespace.someValue);
    },
  }
);

Those would receive the whole store as argument and run once at the appropriate moment.

For the case you mentioned, @luisherranz, in which different types of blocks could want to run the same initialization, you could solve that by defining an action and calling it inside the init callback for each block type.

// Block A
store({
  actions: {
    namespace: {
      init: ({ state }) => {
        library(state.namespace.someValue);
      },
    },
  },
});

// Block B, C, etc.
store({ /* store props (if any) */ }, {
  init: (store) {
    store.actions.namespace.init(store);
  },
});

We could also define different initialization callbacks (init, hydration, whatever) for different lifecycle hooks.

In any case, for the initialization purposes you mentioned, I don't think requiring adding a directive in the HTML would be a good DX. If it is for certain block instances, though, then it's OK. 👍

4 replies

luisherranz Jul 18, 2023
Maintainer Author

I like this idea!

I've been thinking about how lazy loading would work because I think they should work together: i.e., this callback should not be executed until the block is hydrated. I think that this is solved if we delay the execution of the store until the block is about to be hydrated, as I explained in the discussion.

I also like the idea of moving this callback to the options (second parameter) of the store function.

Regarding the naming, as I said in the lazy loading discussion, I suggest using "load" to refer to the "hydration" of a block, so I think we could use "beforeLoad" and "afterLoad" here.

store(
  {
    // regular store..
  },
  {
    beforeLoad: async ({ state }) => {
      // Something that needs to happen before the hydration.
    },
    afterLoad: async ({ state }) => {
      // Something that needs to happen after the hydration.
    },
  }
);

beforeLoad should be used with care as it will block the hydration. If the block is lazy-loaded, it's not that important as it won't affect other blocks. And depending on how we implement the lazy loading, we may do it so we reuse that logic and beforeLoad only blocks the hydration of a particular block even on initial load. But if the site has full-page client-side navigation, all the blocks need to be hydrated at the beginning, meaning that any beforeLoad will block the hydration of all the blocks of the site.

For that reason, I think I would start with afterLoad and wait until we see real use cases for beforeLoad.

luisherranz Jul 18, 2023
Maintainer Author

Oh, we may also need an afterEachLoad callback if they need to do something specific to each DOM reference:

store(
  {
    // regular store..
  },
  {
    afterEachLoad: async ({ state, ref }) => {
      // Something that needs to happen after the hydration, once per block and
      // with access to the DOM reference.
    },
  }
);

But again, let's wait until we see real use cases for that one.

DAreRodz Jul 19, 2023
Collaborator

Oh, we may also need an afterEachLoad callback if they need to do something specific to each DOM reference

I think this is very similar to data-wp-init, isn't it? What would be the differences between them? 🤔

luisherranz Jul 19, 2023
Maintainer Author

Hmm... I guess you're right 🙂

SantosGuillamot · 2023-07-12T06:35:51Z

SantosGuillamot
Jul 12, 2023
Maintainer

I feel the approach David suggests seems easier regarding DX 🙂 Does it make sense to include the different initialization callbacks (init / hydration / whatever) in the store, or should they be another function? I'm not fully familiarized with these patterns, so you will know better than me.

On another note, maybe calling everything init, added to the wp-init directive, might be confusing for developers?

4 replies

DAreRodz Jul 12, 2023
Collaborator

On another note, maybe calling everything init, added to the wp-init directive, might be confusing for developers?

Do you mean using a different name rather than init for the initialization callback? Do you have anything in mind?

SantosGuillamot Jul 12, 2023
Maintainer

Or just clarifying the differences. I didn't think too much about it. But I can imagine people wondering the difference about using a wp-init directive or using init there.

luisherranz Jul 18, 2023
Maintainer Author

Let me know what you think about beforeLoad and afterLoad: link

SantosGuillamot Jul 19, 2023
Maintainer

I like beforeLoad and afterLoad 🙂 I feel it will be easy to understand their purpose.

luisherranz · 2023-07-12T06:43:05Z

luisherranz
Jul 12, 2023
Maintainer Author

wp_add_body_directive( 'data-wp-init--run-library', 'init.namespace.runLibrary' );

I think we should discard the wp_add_body_directive idea for now because people could start using this API to add context to the whole page, which would be an anti-pattern:

wp_add_body_directive( 'data-wp-context', '{ ... some global state ... }' );

0 replies

luisherranz · 2023-08-07T13:26:42Z

luisherranz
Aug 7, 2023
Maintainer Author

@DAreRodz started a PR to add this functionality:

Allow passing optional afterLoad callbacks to store calls #53363

0 replies

luisherranz · 2023-11-07T11:01:16Z

luisherranz
Nov 7, 2023
Maintainer Author

This is no longer needed with the new store() API because the state is accessible from the beginning. It's true that blocks might still need to wait until all the other store parts are loaded, but maybe they can do so with a DOMContentLoaded or a requestIdleCallback call.

New Interactivity `store()` API proposal #53586

We will remove it from the API.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pattern to trigger one callback per page when some block is present #52514

{{title}}

Replies: 5 comments 8 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Pattern to trigger one callback per page when some block is present #52514

luisherranz Jul 11, 2023 Maintainer

Replies: 5 comments · 8 replies

DAreRodz Jul 11, 2023 Collaborator

luisherranz Jul 18, 2023 Maintainer Author

luisherranz Jul 18, 2023 Maintainer Author

DAreRodz Jul 19, 2023 Collaborator

luisherranz Jul 19, 2023 Maintainer Author

SantosGuillamot Jul 12, 2023 Maintainer

DAreRodz Jul 12, 2023 Collaborator

SantosGuillamot Jul 12, 2023 Maintainer

luisherranz Jul 18, 2023 Maintainer Author

SantosGuillamot Jul 19, 2023 Maintainer

luisherranz Jul 12, 2023 Maintainer Author

luisherranz Aug 7, 2023 Maintainer Author

luisherranz Nov 7, 2023 Maintainer Author

luisherranz
Jul 11, 2023
Maintainer

Replies: 5 comments 8 replies

DAreRodz
Jul 11, 2023
Collaborator

luisherranz Jul 18, 2023
Maintainer Author

luisherranz Jul 18, 2023
Maintainer Author

DAreRodz Jul 19, 2023
Collaborator

luisherranz Jul 19, 2023
Maintainer Author

SantosGuillamot
Jul 12, 2023
Maintainer

DAreRodz Jul 12, 2023
Collaborator

SantosGuillamot Jul 12, 2023
Maintainer

luisherranz Jul 18, 2023
Maintainer Author

SantosGuillamot Jul 19, 2023
Maintainer

luisherranz
Jul 12, 2023
Maintainer Author

luisherranz
Aug 7, 2023
Maintainer Author

luisherranz
Nov 7, 2023
Maintainer Author