[Proposal] Top level context flag `in_editor`

[34638a]

Proposal Summary:

In alignment with existing flags in global context of in_production and in_development I would like to propose the addition of the flag in_editor to reflect when the state the the theme is within the BC environment (aka in_production=true) and currently being manipulated via the BC theme editing interface.

Why / Example Situation:

This proposal has originated out of a need to 'fool-proof' the editing of hidden contextual menus without requiring non-intuitive effort on behalf of users.
For example, using Cornerstone build 6.16.1 to show a hidden element (example of the mobile navigation menu as it is easy to demonstrate):
There is a mobile menu that is "hidden by default" by a hamburger button (standard stuff). If one day there was to be a editable region inserted within this menu (eg. {{{ region name="mobile-menu--global" }}} ) it would not be possible to see this element for editing without doing the following process:

1. Open theme editor with Cornerstone v6.16.1
2. On top nav, press mobile or tablet scaling view to reveal burger
3. On top nav, press "preview" button to change to preview mode
4. In preview window, click menu burger to expand mobile menu
5. Without clicking within the preview window, On top nav, press "design" button

If there was to be a region within the mobile menu, these would be the steps required to first: A. see that it exists, and B. edit the content within this menu. This also applies to previewing the content within the mobile menu for aesthetic edits (colour, font, boldness, etc.), and should the editor iframe be reloaded / refreshed by any means ( see schema.json flag force_reload=true ), the preview state would be lost and the process would need to be repeated to view the menu once again before more tweaks can be made.

Proposal Usecase:

If such a flag would be able to exist, this flag would enable you to use the existing and block helper to hide and show contextual elements within the editor via checkbox settings in config.json and schema.json. For example the checkbox could be used to force the state of dropdowns, modal popups, marketing banners, side menus, off-screens, and carousel pages for editing aesthetic, widgets and regions within them, without the need to force a state via the preview tab, or via js detection methods (aka code on the live site that only exists to run within the editor iframe). Without this proposed flag, adding checkboxes to the settings with the purpose of using them to force state for editing, any setting made for this purpose can and will be forgotten about after editing is complete, which will result in unintended elements being locked in a unintended state in live.

Examples

For example if one were to create a checkbox setting called debug-default-show-marketing-modal: false and associated entry within schema.json to enable toggling the bound value; this created value could be used to show and hide a global popup marketing modal as the default state when the page loads so it is easy to edit between refreshes of the editor.

Examples are using the TailwindCSS v3 system of styling for quick reference.
https://v3.tailwindcss.com/docs/installation

Example for forcing a modal to appear to edit a marketing popup without flag.

<div class="tw-common-modal hidden data-[show=true]:block" show={{#if theme_settings.debug-default-show-marketing-modal}}"false"{{else}}"true"{{/if}}>
    <button class="tw-common-modal-button" onclick="()=>closemodal();">Close Modal</button>
    ...Modal Content...
</div>

In this example, the value is used to modify a data attribute on the element so that the modal is always visible when the page content loads, and pressing the close modal button, toggles the state of the attribute via some JS. Should the modal be closed after editing within the preview window by clicking the "close modal" button, it can be easy to forget that the editor checkbox for debug-default-show-marketing-modal is currently set to true, and if the theme is saved / published in this state, the modal will now be open and visible on the live site as the first thing that customers see.

Example for forcing a modal to appear to edit a marketing popup with flag.

<div class="tw-common-modal hidden data-[show=true]:block" show={{#and in_editor theme_settings.debug-default-show-marketing-modal}}"true"{{else}}"false"{{/and}}>
    <button class="tw-common-modal-button" onclick="()=>closemodal();">Close Modal</button>
    ...Modal Content...
</div>

The key difference between the with and without examples is that the presence of the flag allows for a "safety net" case where the convenience of having the modal visible for editing does not reflect outwards to the live site without intention due to the whole of the and block resolving to false when outside of the editor as the in_editor flag would return false when viewing the site as a customer.

---

Thanks for your time and consideration,

• Jordan