Replies: 1 comment 1 reply
-
|
If the components are only used inside the project, I suggest keeping the interface (the props) as small as necessary to do their job. Expand them if and when necessary. If you do, make the previous behavior the default for backwards compatibility. Also, treat the components as black boxes. Don't expose internal details to the outside unnecessarily. If you add props, make them "semantic" rather than technical. For example, don't have a "color" property for arbitrary colors - rather have an "intention" property with values like "success", "error" etc. This makes it easier to switch the implementation down the line. E.g., if the color for the "success" intention should switch to a lighter green, you don't have to change each instance if the component. These constraints help you to get a consistent UI that's easier to maintain and change. These are just my personal guidelines. Use them, adjust them, and most importantly break them whenever it makes sense. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I have a bit of troubles working with components. For my project, I've created a
Labeland anInputcomponents. The idea is to simply enforce classes to keep all instances similar.However, it is difficult to handle the properties of both when they are used into a single component. For my case, I used both in an
EmailInput. How should I handle the properties of components?Should each component only define the properties they use and retro-actively add new one if needed? Should each component inherit the properties of every component it's made of?
I tried to inherit each properties, but
EmailInputdefines the property type from the input component. Inheriting only exposed it, each led to errors.Beta Was this translation helpful? Give feedback.
All reactions