Replies: 2 comments
-
I think this would be a useful addition. I'll leave some code references related to which parts of the source code would require changes to implement this.
react-cosmos/packages/react-cosmos-core/src/fixtureState/types.ts Lines 67 to 72 in 087a590
If someone wants to take charge and implement this feel free and let me know if you need more help. It's not a simple contribution by any means because you're touching 3 packages in the process. But will some luck, if you don't hit any roadblocks, it's a doable outside contribution of considerable impact. I wouldn't worry about tests for the UI changes (although changes to the Select component should be sensible because it is a reusable primitive). But one or two brief useSelect tests similar to these that feature fixture state with group options would be useful. |
Beta Was this translation helpful? Give feedback.
-
I have completed an initial implementation, which can be found in the following GitHub pull request: link. I would appreciate your feedback on any potential improvements or changes you would suggest. Tomorrow I will have to work again, but I will try to find time this week to enhance the test coverage. |
Beta Was this translation helpful? Give feedback.
-
In situations where a select field includes a large number of options, it's common for visual clarity to diminish, making it prone to "word skipping." This means users may inadvertently select an unintended option due to the overwhelming number of choices. This challenge becomes more pronounced when the options are predominantly similar, exacerbating the difficulty of differentiation.
Essentially, when a select field becomes visually fuzzy and users experience word skipping, it heightens the risk of unintentional selection. This issue becomes even more challenging when the available options share similarities.
As a result, the user experience and efficiency of utilizing Cosmos may be compromised. The cognitive burden of navigating through a visually fuzzy select field and the increased likelihood of unintentional selections can impede the smooth workflow within the Cosmos environment. This reduction in efficiency could hinder productivity and potentially diminish the overall usability of the tool.
Use case:
In certain scenarios, there is a need for us to provide users with a predefined set of CSS Variables for specific components. For example, let's consider the component
<Flex gap="cssPropertyValue" />
, where users can specify thegap
using CSS Variables like<Flex gap="var(--vendor-spacing-big)" />
. In this case, it would be advantageous to have an improved approach for selecting CSS Variables directly from the controls panel.Currently, the list of CSS Variables includes all options, regardless of whether they are compatible with the specific component or not. To address this use case, a potential solution is to introduce a grouping mechanism that allows users to easily differentiate between different types or categories of CSS Variables. This grouping feature would enhance the usability of the controls panel, making it simpler for users to locate and select the relevant CSS Variables that are compatible with the component they are working with.
Beta Was this translation helpful? Give feedback.
All reactions