Export different code depending on the context (Edit, Save, or View)

[luisherranz]

I've been thinking a bit about this, and the best idea that comes to my mind is to use suffixes: file.env.js notation, like the one used by React Native (file.native.js, file.ios.js and file.android.js) or React Server Components (file.client.js and file.server.js).

For example, if a person imports RichText like this:

import { RichText } from "@wordpress/block-editor";

Webpack would bundle this:

• Edit: @wordpress/block-editor/src/components/rich-text/index.edit.js
• Save: @wordpress/block-editor/src/components/rich-text/index.save.js
• Frontend/View: @wordpress/block-editor/src/components/rich-text/index.view.js

We would need to figure out:

• How can we combine it with other suffixes (like file.native.js)? Is there a precedent?
• How can we differentiate between Edit and Save (they share the same bundle right now)? Or how to use separate bundles for Edit and Save.

---

Apart from that, does anyone have any other idea about doing this?

[luisherranz]

For context, we need this (or an alternative solution to this) to be able to do things like:

• Allow hooks in the Save component so people can use their View component for both the save and frontend (similar to this hack)
• Avoid sending unnecessary code to the frontend (for example, serialize.js in @wordpress/element)
• Switch to Preact in the frontend (@wordpress/element)
• Be able to use the same component in the different environments without problems, and without sending unnecessary code to the frontend (for example, RichText)

[gziolo]

Switch to Preact in the frontend (@wordpress/element)

We talked about that idea agains with @sgomes in the last week.

Allow hooks in the Save component so people can use their View component for both the save and frontend (similar to this hack)

It's definitely something that would provide better developer experience. It must be a real struggle for plugin developers. The most recent example where it created confusion: WordPress/gutenberg#43201.

[luisherranz]

I was just answering to that issue 😄

[sgomes]

Switch to Preact in the frontend (@wordpress/element)

This would make me so happy 🥹

I've been thinking a bit about this, and the best idea that comes to my mind is to use suffixes

Have you considered having different, well-known paths instead (build-module/edit/, build-module/save/, build-module/view/)?

These could be complemented with custom entries in package.json (e.g. block:edit, block:save, block:view) to optionally make configuring a little easier, if hardcoding a well-known path into your config is undesirable. E.g., for a project that is only making use of viewing features, and building with webpack:

resolve: {
  mainFields: [ 'block:view', 'browser', 'module', 'main' ],
}

This would then make it easier to still have variation within each directory based on the other suffixes you've mentioned.

[luisherranz]

Yeah, I thought about it, but it seemed less flexible to me, especially when the code differences are deep inside the package and not at the root. But we could try it as well 🙂

[sgomes]

Yes, it's definitely less flexible in that situation! If that turns out to be the case, then the original approach is a better fit 👍

[luisherranz]

Due to the direction we have taken in this initiative, exporting different code depending on the context is no longer necessary, at least for now.

In addition, it could be the case that the method we use to share components between contexts is not the one based on imports as proposed in the initial post, but one closer to the directive-based templating, such as:

<div class="wp-block-some-block">
  <wp-rich-text text="attributes.text" />
</div>