- Issue created by @jessebaker
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
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.) - 🇬🇧United Kingdom jessebaker
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.
- 🇫🇮Finland lauriii Finland
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.
- 🇫🇮Finland lauriii Finland
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.
- 🇬🇧United Kingdom jessebaker
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.
- 🇬🇧United Kingdom jessebaker
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!
- 🇫🇮Finland lauriii Finland
The components load really fast but I definitely still see the loading animation briefly even if I wait for bunch of time before:
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
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:
- Components
- Code
- Dynamic Components
- Overrides
But to anybody who never writes components themselves, this would be more logical:
- Components
- Dynamic Components
- Code
- 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? 🤔
- 🇬🇧United Kingdom jessebaker
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.
- First commit to issue fork.
-
hooroomoo →
committed e70edb05 on 0.x authored by
jessebaker →
Issue #3525813 by jessebaker, hooroomoo, lauriii, callumharrod: Move "...
-
hooroomoo →
committed e70edb05 on 0.x authored by
jessebaker →