-
Notifications
You must be signed in to change notification settings - Fork 2
[RFC] Alternatives to Awkward Variant Modifiers #2
Comments
I worry that this proposal means that components will have significantly more props on them. I completely agree with your initial suggestion though that the implicit boolean versus string is unintuitive. What if we did something like |
Definitely agree that an explosion of props is not ideal. That said, I'm not convinced that a default string is the answer, since it would be extremely difficult to come up with a value that is as universal and straightforward as a boolean, especially since the shorthand for Taking a step back, it seems like there's a meaningful distinction between the two approaches. With This seems like a core distinction, and may help us figure out what approach to take. Is it important that we support varying magnitudes of a property (or certain properties)? If so, P.S. For the sake of argument, in my opinion |
Agreed here. I think we may want to review all SUIR cases where a prop we have modifying props that are enumerated as either true or an expected set of strings. Looking at them all together might shake out a better baseline string. Or different solution. |
Note, the result of this conversation will be a direct update to the API guidelines for contributing: https://github.com/levithomason/stardust/blob/master/.github/CONTRIBUTING.md#api It is worth reviewing that ^ to understand how and why we have the 4 types of props in the library currently. |
Additionally, I was working on an "API Explorer" which I think I'll return to. I want to analyze the library's current components and props. We should know how many different props we have, how many conventions there are, which props are global, which are isolated to a single component, etc. This will enable us to make data driven decisions on reducing API surface moving forward. Generating this information per PR will also enable us to review API impacts on a per PR basis. |
Moved to microsoft/fluent-ui-react#2. |
Feature Request
Problem description
In Semantic UI V1 we supported modifiers/variants such as:
The problem with this is that it's extremely unintuitive, reads awkwardly, and overloads what should be a boolean or otherwise mutually exclusive property (
basic
).Proposed solution
This issue is designed to encourage conversation around alternatives to this problem. One simple idea would be to support something like:
Better ideas are encouraged.
The text was updated successfully, but these errors were encountered: