Displaying and creating folders

Parent issue is already tracked as a stable blocker.

Question 1

Step 1 in the Libraries instructions includes
Merge the listing of Components and Dynamic components under the label Components.

Dynamic components are already organized into collapsible subsections sections based on their block_category:, which would mean two different forms of collection next to each other:

1. Folders (ui configurable)
2. Block categories (hard coded)

Perhaps this is fine and is why there's no additional explanation, but I'd like to confirm that.

Question 2

Is adding a new folder done via a dialog with a single text field for the dialog name, or was a different type of interaction envisioned? Are there any format requirements of the name provided?

Question 3

In the screenshot for Manage Library the root level shows only folders. Item 4 mentions "Keep support for displaying items at the root level." which I believe means un-foldered items can be displayed alongside the folders.

• Could I get confirmation of this and (if capacity allows) a visual example?
• Assuming this is the case, should folders and components be listed interchangeably as alphabetical order dictates, or should they be grouped together and alphabetically sorted within those groups? Is this different depending on if we're in Library or Manage Library?

Question 4

In the screenshot for Manage Library I don't see any controls where one might be able to rename or delete existing folders. Even if this is something to be added later, knowing where the controls might be will inform how this gets implemented.

Question 5

I could not find a folder icon in Radix. Could the svg used in the designs be provided in this issue?

Question 6

Do folder weights have any impact at this time? Based on the current requirements it looks like they're all being set to 0 and sorting is alphabetical - which is fine of course but I wanted to be sure I wasn't overlooking somewhere they get used.

1. Question 1: I believe the intention is to allow dynamic components to be placed in categories in the same way that we could group any other component type. This is to allow a user to control where every component goes, including dynamic components. The only thing that wouldn't be able to be grouped with components is the code used for code components.
2. Question 2: There may be another method to add a new folder in the future. However, for now it's only manage by a dialog. I didn't have any formatting as a requirement, so I don't think it's needed here.
3. Question 3: Not sure if we're allowing top level components (not in a folder.). I'll await confirmation before adding designs.
4. Question 4: The folders have a context menu available on hover. From here you can delete or rename folders.
5. Question 5: Adding code for SVG here as d.org doesn't allow uploading svgs...
6. Question 6: I hadn't planned to make it alphabetical. My intention was when a new folder is added, it is added to the end of the list of folders. These can be freely moved up/down (changing the weight) so they can be placed anywhere within the sidebar hierarchy.

<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
<mask id="mask0_14031_57331" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="0" y="0" width="16" height="16">
<rect x="0.5" y="0.5" width="15" height="15" fill="#D9D9D9"/>
</mask>
<g mask="url(#mask0_14031_57331)">
<path d="M3.19234 12.6875C2.87661 12.6875 2.60937 12.5781 2.39062 12.3594C2.17188 12.1406 2.0625 11.8734 2.0625 11.5577V4.44234C2.0625 4.12661 2.17188 3.85938 2.39062 3.64063C2.60937 3.42188 2.87661 3.3125 3.19234 3.3125H6.15625C6.30687 3.3125 6.45172 3.34177 6.59078 3.40031C6.72974 3.45875 6.85052 3.53927 6.95313 3.64188L7.87375 4.5625H12.8077C13.1234 4.5625 13.3906 4.67188 13.6094 4.89063C13.8281 5.10938 13.9375 5.37661 13.9375 5.69234V11.5577C13.9375 11.8734 13.8281 12.1406 13.6094 12.3594C13.3906 12.5781 13.1234 12.6875 12.8077 12.6875H3.19234ZM3.19234 11.75H12.8077C12.8638 11.75 12.9099 11.732 12.9459 11.6959C12.982 11.6599 13 11.6138 13 11.5577V5.69234C13 5.6362 12.982 5.5901 12.9459 5.55406C12.9099 5.51802 12.8638 5.5 12.8077 5.5H7.49031L6.29453 4.30406C6.27443 4.28406 6.25339 4.27005 6.23141 4.26203C6.20932 4.25401 6.18625 4.25 6.16219 4.25H3.19234C3.1362 4.25 3.0901 4.26802 3.05406 4.30406C3.01802 4.3401 3 4.3862 3 4.44234V11.5577C3 11.6138 3.01802 11.6599 3.05406 11.6959C3.0901 11.732 3.1362 11.75 3.19234 11.75Z" fill="#00051D" fill-opacity="0.454902"/>
</g>
</svg>

#3539729: Implement Folder config entity is in! That means this is unblocked now (and won't need to chase changes anymore 😅).

Setting to NR. e2e tests, particularly Playwright at the moment, are a bit flaky, so don't let fails there get in the way of a review.. there's plenty that needs looking at.

Library

Manage Library

Seems like this incorporated most of the scope of #3541364: Delete folders? That makes this MR way bigger (and much more back-end centric) than what is described in this issue's summary.

If this is just more pragmatic: WFM. But landing this massive MR (44 files, +2584, -285) then is likely to take longer.

Discussed with @bnjmnm: this includes the auto-creation subset of #3541364, and we won't be extracting that out of this MR: that'll be too painful/not worth it. See #3541364-5: Delete folders.

Nice progress!

Most important: the Folder auto-creation logic is incorrect AFAICT: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

Because it is easily missed: I reopened a number of threads that have been IMHO closed too early.

Discussed with @bnjmnm last night. We want to get this merged before the big rename.

Ben tackled the needed FE changes last night, I'll tackle the BE changes needed to be able to merge this (if any remain, that is), plus updating related issues to ensure whatever scope this did not tackle, will be tackled elsewhere.

For the BE, follow-ups:

• I updated #3541364: Delete folders to re-expand its scope again.
• @bnjmnm opened #3543390: [PP-1] Issue with calls to Component::create()->save() seemingly calling postSave() multiple times with $update===FALSE (thanks!) — but I addressed it here, so I was able to close it already. I addressed it here because it made me doubt data integrity, and anything like that I can't justify merging without understanding (EDIT: to clarify, I then start to question if this massive house of cards with validation to ensure its stability is actually missing something that I should've spotted. 😅).

Still to do: organize follow-up issues for @balintbrews' remarks in #17. I've created one of those (for #17.1): #3543533: [PP-1] Display both internal and exposed code components in "Manage library". In doing so, I paved the path as much in this MR as I could, which involved making xb_test_folders use the test code components that already existed in HEAD before this MR (which are exposed).

Doing that surfaced an interesting consequence of a loose end from back in January: JsComponent::createConfigEntity() always sets category: @todo, which now results in a "@todo" Folder getting created for Components, whenever a code component changes from status: false to status: true. Updated test expectations. We'll have to fix it at #3541364-9: Delete folders.

Now just needs a conflict to be solved, @jessebaker is handling that :)

Yay, it's in! 🚀

Back to @bnjmnm for creating follow-ups for @balintbrews' #17 — except #17.1, that's already taken care of — see #20.

Followups created as needed:

• Already addressed in this issue
• Appearance of empty folders need to be adjusted, see #note_575777.
• Components and patterns should not be draggable to the canvas from Manage library, see #note_575781
• #3543795: Broaden Manage Library -> Code Tab scope Covers "Display both internal and exposed code components in Manage library under the Code tab. See #16". I know it was stated above that this was already addressed and discussed in #20 but I'm not seeing exposed components in the Code tab, just internal - if I missed something here sorry about the noise
• #3543796: Update hover styling for folders in Library and Manage library Covers "Appearance of hovered folders need to be adjusted, see #note_575778."
• #3543800: Have "Add Folder" form use @/components/Dialog Covers "Adding new folders should use @/components/Dialog and handle errors, see #note_575780."
• #3543804: Manage Library / Code Component UI refinements Covers
  • When a new code component is created from Library, the Code tab of Manage library should be opened.
  • When a code component is clicked under Manage Library, and the current route is not the code editor, the Code tab should remain selected.

Thanks! (Linking to make this issue more discoverable from those new issues.)

Actually, AFAICT #3543795: Broaden Manage Library -> Code Tab scope is a duplicate of what I already created: #3543533: [PP-1] Display both internal and exposed code components in "Manage library". (See #20.) Closed.

Verified below scenarios and please check failing scenarios TC9, TC10 and TC19:

I have created follow-up issues for the bugs identified above:

• Cannot create or view folders in the "Manage Library" Code tab unless at least one code component exists:
  
  https://www.drupal.org/project/canvas/issues/3545660
  
• No user-facing error is displayed when creating a new folder with a duplicate name in "Manage Library":
  
  https://www.drupal.org/project/canvas/issues/3545655
  
• Unable to delete code components from Manage Library due to a 403 error on delete:
  
  https://www.drupal.org/project/canvas/issues/3544776