Proposal: Adjust representation of Regions in the Layers UI

Created on 10 January 2025, 4 months ago

Overview

In the designs, the way Regions are represented differs from the current codebase. In the code, currently, the Layers panel is basically a 1:1 representation of how the Regions/Components data is organised in JSON. In Figma, the design shows Regions as siblings of the components in the current Content block.

Proposed resolution

I think, before the work is undertaken to implement the UI as shown in the design there should be discussion around abstracting the regions view in this way vs keeping it closer to the data model representation.

User interface changes

Feature request
Status

Postponed: needs info

Version

0.0

Component

Page builder

Created by

🇬🇧United Kingdom jessebaker

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jessebaker
  • 🇫🇮Finland lauriii Finland
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Per @lauriii in chat.

  • Adding two screenshots from the Figma designs showcasing what the layers panel currently looks like. For pages we are only showing the content region and it's items. No other regions are surfaced to the user currently, however, I will be looking at how we expose regions when you are creating a template for a content type.

    Here it shows what it looks like when a region is selected:

    Here it shows what it looks like when a component inside of a region is selected:

  • 🇬🇧United Kingdom jessebaker

    Following on discussions on this that happened in meetings:

    The Content "region" is not actually a region and it should not be displayed to look the same as the other Global Regions (which are shown in green).

    Furthermore, at a future point a page might have more than one Content region (once we start looking at templates exposing XB slots) so we need to account for that.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    once we start looking at templates exposing XB slots

    This is referring to 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active .

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    @lauriii posted this at #3476354-20: Slot with a placeholder is flickering when adding a new component :

    Even though the root is close to a region, it doesn't cascade outside the current page. Therefore we should not be using green for the root as green is supposed to signify that changes inside that area cascade outside the current page.

    Blue vs purple is supposed to signify components vs elements. We don't really have elements at this point so pretty much everything should be either purple or green.

    Slots don't have their own color at the moment; they should inherit the color of their parent. In this case since we're using components, they should be purple.

    @lauriii and @callumharrod What is the color and icon supposed to be for Content Type Slots? We'll work on adding those in 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active , but until then, in this issue, the sole special "Content region" (which isn't really a region, see @jessebaker's #5) should really be considered the only Content Type Slot, and so merit its own affordance (color + icon).

    IOW: this issue is both an opportunity to

    1. remove the confusion around the (theme/page template) region — which XB never allows to be customized, unlike when using core's Block functionality to populate regions.
    2. and simultaneously get a gentle head start on something we know will be needed for 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active

    IOW: for now, there'll be a single one of these, and it'll always be named , but after #3455629, there'll be 0, 1 or N of these, with names chosen by the Site Builder.

Production build 0.71.5 2024