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.

I just had a conversation with @lauriii. Internal code components should live under Manage library. I adjusted the issue summary accordingly.

Answers to questions in #5:

1. I missed when we added that. 🙂 Those need to be replaced by folders, which will be initially auto-created from those block categories in 📌 Expand Folder entity functionality Active . In other words, folders are superseding the hard-coded block categories.
2. Correct, single text field in a dialog, @/components/Dialog should be sufficient. The only requirement is that folder names need to be unique within a parent (i.e. components, patterns, code).
3. Confirmed. I'll ping @callumharrod for the visual example.
4. I would vote for grouping them together, starting with folders. @callumharrod, can you please confirm? It should be the same in Library and Manage library.
5. See ✨ Renaming, moving, and deleting folders through contextual menu Active .
6. @callumharrod, please.
7. We'll expand on that in ✨ Renaming, moving, and deleting folders through contextual menu Active , alphabetical order and 0 weights are what's in scope of this issue.

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>

#8.3: Yes, we should. I discussed that with @lauriii.

📌 Implement Category config entity Active 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 📌 Expand Folder entity functionality Active ? 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 basically includes 📌 Expand Folder entity functionality Active — or at least a subset. See #3541364-5: Auto-create folders & disable components when folders get deleted → .

balintbrews → credited jessebaker → .

A proposal by @jessebaker that we decided to implement:

In Manage library, let's display both internal and exposed code components under the Code tab. The backend already supports the organization into folders for JavaScriptComponent entities, which will be separate from organizing the Component entities, which will take effect under the Components tab — where exposed code components are represented by Component entities.

I approved from the frontend side with the following observations:

1. Display both internal and exposed code components in Manage library under the Code tab. See #16.
2. When a new code component is created from Library, the Code tab of Manage library should be opened.
3. When a code component is clicked under Manage Library, and the current route is not the code editor, the Code tab should remain selected.
4. Appearance of empty folders need to be adjusted, see #note_575777.
5. Appearance of hovered folders need to be adjusted, see #note_575778.
6. Adding new folders should use @/components/Dialog and handle errors, see #note_575780.
7. Components and patterns should not be draggable to the canvas from Manage library, see #note_575781.

I think the issue can land without these. @bnjmnm, I'll leave it up to you how you would like to structure the follow-up issue(s).

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 📌 Expand Folder entity functionality Active to re-expand its scope again.
• @bnjmnm opened 🐛 Issue with calls to Component::create()->save() seemingly calling postSave() multiple times with $update===FALSE Postponed (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.

Still to do: organize follow-up issues for @balintbrews' remarks in #17. I've created one of those (for #17.1): 📌 Display both internal and exposed code components in "Manage library" Active . 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: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1453/diffs?commit_id=a332667be728d96251d27771f3d33feaceddba4a

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
• ✨ Broaden Manage Library -> Code Tab scope Active 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
• 📌 Folder style updates Postponed Covers "Appearance of hovered folders need to be adjusted, see #note_575778."
• 📌 Have "Add Folder" form use @/components/Dialog Active Covers "Adding new folders should use @/components/Dialog and handle errors, see #note_575780."
• 📌 Manage Library / Code Component UI refinements Active 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 ✨ Broaden Manage Library -> Code Tab scope Active is a duplicate of what I already created: 📌 Display both internal and exposed code components in "Manage library" Active . (See #20.) Closed.

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