[META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3462219. -->
Reported by: [catch](https://www.drupal.org/user/35733)
>>>
<h3 id="overview">Overview</h3>
<p>Extracting this from <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/drupal/issues/3440578" title="Status: Postponed">#3440578: [PP-2] JSON-based data storage proposal for component-based page building</a></span> because that's a long issue with a lot of different discussions, and it probably needs its own issue.</p>
<p>Both core search module and search_api module rely on view modes so that site builders can decide how content gets rendered into the search index. For core search module it hard codes the 'search' view mode, for search_api, you can configure which view mode to use.</p>
<p>The search view mode almost always wants to have all of the field content that the default view mode does (body field especially), but without elements that would 'pollute' the search results like field labels, related content blocks, CTAs, social widgets etc. so that if I search for "newsletter" or "Facebook" I don't get every article on the site back in the results, but only the ones with content actually mentioning newsletters or Facebook.</p>
<p>This means the search view mode is 99.9% of the time going to want to render both the 'fixed' and 'loose' content that is entered for the default view mode.</p>
<p>There is a very similar problem if you wanted to show for example the 'full' content of the entity in a newsletter subscription via an e-mail view mode - simplenews does this I think. When rendering content for a newsletter, you would probably want to remove a newsletter sign-up element, but probably different things to what you'd remove for search indexing otherwise.</p>
<h3 id="proposed-resolution">Proposed resolution</h3>
<p>I can see how we could do this if all prop content is in entity fields (such as the 'field union JSON' model from <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/drupal/issues/3440578" title="Status: Postponed">#3440578: [PP-2] JSON-based data storage proposal for component-based page building</a></span>), because we already have a model for configuring how those are displayed in different view modes. Although it would still need some work specific to 'field union JSON' fields because each delta could be a different union, and hence use a different component/formatter - but the data would be equally available regardless of which view mode you're in.</p>
<p>I have no idea how it would work with the current XB data model, because the 'static prop' data is all in a single field value (JSON blob), and that single field value holds content that is specific to a view mode. We would need to provide a way for experience builder to configure rendering that data in a different way - but it's arbitrary what data is in there.</p>
<h3 id="ui-changes">User interface changes</h3>
> Related issue: [Issue #3440578](https://www.drupal.org/node/3440578)
> Related issue: [Issue #3485742](https://www.drupal.org/node/3485742)
> Related issue: [Issue #3455629](https://www.drupal.org/node/3455629)
> Related issue: [Issue #3483301](https://www.drupal.org/node/3483301)
> Related issue: [Issue #3523844](https://www.drupal.org/node/3523844)
> Related issue: [Issue #3534466](https://www.drupal.org/node/3534466)
issue