Move "Dynamic Components" into the Library

Nice! I think that'll aid their discoverability 👍

Q: why is after Code? That feels wrong. But … I guess that's really dependent on what you as a user are doing! I think we should make those reorderable 😇 (Out of scope here of course.)

RE #2: I think they are just alphabetical.

I have seen future design ideas (that have not yet been approved) that show the components and dynamic components merged into the same part of the library so I think this part of the UI is still subject to change.

Given that it is likely to change, as part of this, I will place Dynamic components next to Components and above Code.

Could we place these after code? Then these are in the order of how frequently they are going to be accessed. It's also more logical because Components + Code are related, and Dynamic Components + Overrides are related.

I see you added loading states to the different component categories. I'm thinking it would probably make sense to load at least components on the initial load to avoid users seeing the loading animation.

I've raised ✨ Clicking an item in the library should NOT insert it into the page Active as a follow up based on findings I made while working on this.

RE #7 I believe we do already request the full list of components on page load. The loading state should really not be seen by users unless they load the page on a slow connection and IMMEDIATELY switch to the library tab.

The loading state is more for the benefit of things like our Cypress E2E tests that move much faster than a human!

The components load really fast but I definitely still see the loading animation briefly even if I wait for bunch of time before:

It's also more logical because Components + Code are related, and Dynamic Components + Overrides are related.

That's the logic from your POV. Each user of XB can have their own perspective/logic.

You propose:

1. Components
2. Code
3. Dynamic Components
4. Overrides

But to anybody who never writes components themselves, this would be more logical:

1. Components
2. Dynamic Components
3. Code
4. Overrides

(Yes, not having the administer code components permission would also hide and , but it'd still be a thing for me to actively ignore if I did have that permission.)

P.S.: Kind of out of scope but related: I think we're going with a different name than "overrides", per 🌱 Plan how to evolve code component overrides Active , right? 🤔

RE: #10 I've made a follow up because this MR is already a bit busy 🐛 [PP-1] Reduce unnecessary api calls when opening Components list Active

RE: #11 I think the UX of the library is still evolving and I've seen newer designs that don't even separate Components/Dynamic Components/Code Components and instead have them all in a single list (with filtering options) and even a "folder" structure based on categories. For now I will leave in the order described in #4. It's trivial to change at a later point if we want to.

hooroomoo → credited callumharrod → .

adding designer credit