Overview

Sections are pre-configured compositions of components (i.e. a tree of components with some pre-defined content). How sections are different from components is that content creators are able to de-compose them, unlike components where content creators can only interact with the properties and slots provided by the component.

Proposed resolution

For the purposes of the demo, it would be sufficient to implement this on the client side only. In other words, the UI would be storing a hard-coded list of sections, created using the demo components for the purposes of the demo. We can use hard-coded images for the purposes of the demo, before we have implemented #3462636: Preview component when selecting in left sidebar.

User interface changes

Design

Implementation

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

lauriii created an issue. See original summary.

wim leers’s picture

Title: Implement the concept of sections within the client » [PP-1] Implement the concept of sections within the client

We can use hard-coded images for the purposes of the demo, before we have implemented #3462636: Auto-generating component preview images.

IMHO that'd be a waste of time, because those images would be more of a pain to generate than implementing #3462636-2: Preview component when selecting in left sidebar?

wim leers’s picture

Title: [PP-1] Implement the concept of sections within the client » [PP-2] Implement the concept of sections within the client
Status: Active » Postponed
Related issues: +#3455036: Clarify "components" vs "elements" vs "patterns"

More importantly:

Sections are pre-configured compositions of components (i.e. a tree of components with some pre-defined content). How sections are different from components is that content creators are able to de-compose them, unlike components where content creators can only interact with the properties and slots provided by the component.

I am still very worried that "a section" is ambiguously defined, #3455036 exists to clarify that (and has been open for a month now). See #3455036-13: Clarify "components" vs "elements" vs "patterns", where I explained that we need this to be documented first, so that all these UI implementation issues can refer to that to get clarifications/answers without needing to talk to you.

lauriii’s picture

#2: I agree we should not implement a backend API for this because we know it would be replaced by the auto-generated images. This would be only in the scope of the client implementation. FWIW, I created this issue with @jessebaker and he didn't raise concerns over this approach. Maybe he can explicitly confirm if he thinks it's okay to keep both of these issues to be actionable in parallel.

#3: Can you point out what are the remaining questions in regards to sections? To me it seems that it's pretty clear what sections are in comparison to components and elements. My perception is that what's remaining in relation to sections is making sure that section as a term makes sense. If naming is all that's remaining to be clarified, I'm not sure we should make it a blocker to this.

wim leers’s picture

#4 RE: #3: Let's continue this discussion in the issue that exists for specifically this purpose: #3455036-17: Clarify "components" vs "elements" vs "patterns".

wim leers’s picture

Title: [PP-2] Implement the concept of sections within the client » Implement the concept of sections within the client
Assigned: Unassigned » jessebaker
Status: Postponed » Needs review
Issue tags: +Needs issue summary update

As described in #2, #3462636: Preview component when selecting in left sidebar landed, so that's one fewer blocker 👍

But … the closely related #3460952: Implement add button for top level item (section) landed already. How does that affect this issue's scope? Tagging Needs issue summary update, because AFAICT there's nothing blocking this anymore? 🤔 Assigning to front-end lead @jessebaker to get clarity on that.

jessebaker made their first commit to this issue’s fork.

jessebaker’s picture

Status: Needs review » Active

balintbrews made their first commit to this issue’s fork.

jessebaker’s picture

Assigned: jessebaker » balintbrews
balintbrews’s picture

I posted a todo list in the MR description based on my assessment of the remaining work.

balintbrews’s picture

From the list of remaining work:

Review and potentially revisit how preview thumbnails for the listed components and sections in ListItem.tsx are rendered. There is a failing test currently in xb-general.cy.js that seems to be showing a real bug. Plus, this might be a good opportunity to figure out how those preview thumbnails will play nicely with overflow: scroll added in #3463798: No upward auto-scroll when components are dragged.

I now consider this item done — or at least something that doesn't require more action in this MR. I realized that the test failure also frequently happens in 0.x, so it is not being introduced by this MR. We're better off opening a separate issue to address it. The preview thumbnails were fixed in #3471102: Unable to scroll component list by rendering them in a portal. I carried out the same change here in 3471102, since this MR refactors the component where this was previously added.

I also marked error handling tasks as done (and with strikethrough) after realizing that it is work all the methods could use in those files, and it doesn't make sense to just do it for the couple of new ones this MR adds. We should target them all at once at one point.

balintbrews’s picture

Assigned: balintbrews » bnjmnm
Status: Active » Needs review

This is now ready for a review. @jessebaker had already done all the heavy lifting, so I approved the MR, and I really would like @bnjmnm's review before we merge.

balintbrews’s picture

lauriii’s picture

Assigned: bnjmnm » jessebaker

Assigning for @jessebaker to continue

wim leers’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs issue summary update +Needs followup

The back-end side LGTM now :)

AFAICT

_Nice to have:_ Refactor `layoutModelSlice.ts::replaceUUIDsAndUpdateModel()` and `layoutModelSlice.ts::insertMultipleNodes()`, make them unit testable, then write unit tests

is not yet addressed.

That's fine: it's a nice-to-have. Can we extract a follow-up issue for that, and have a less experienced team member take that on? 🙏

  • jessebaker committed 3d41e58f on 0.x
    Issue #3463300 by jessebaker, balintbrews, wim leers: Implement the...
jessebaker’s picture

Assigned: jessebaker » Unassigned
Status: Reviewed & tested by the community » Fixed

All fixed! Hooray!

Follow up to address that last nice to have is created here: #3472089: Improve/Refactor replaceUUIDsAndUpdateModel() and insertMultipleNodes().

wim leers’s picture

kristen pol’s picture

I see the "Fake Section 2" section listed now.

  1. Will there be other sections created for Barcelona?
  2. Is SDDS supposed to create sections?
  3. How do you create sections? Is there documentation?
lauriii’s picture

wim leers’s picture

Issue summary: View changes
StatusFileSize
new603.1 KB

A screenshot was missing.

wim leers’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.