Questions to ask when planning UI Module or components

components

• How many UI states does this component have?
• Can I easily can I validate the current UI state?
• How ergonomic are my styles? (i.e. how quickly can someone else read them)
• Am I creating sensible UI abstractions? Or am I drawing boxes around the visual design?
• Am I separating layout form visual design where possible?
• Am I separating application logic from UI components?
• Am I communicating my intentions to other developers and giving semantic meaning to components.
• Event In Bind in A component it self on parent component
• Component have mechanism for inter-component communication
• total events in a component 
• total option in a component
• default value of component 
• component option is extendable 
• load its dependency  js and css files .

A container component:
      contains no presentation or layout styles
      should not render mark-up (except children)
      can wrap layout and presentation components may fetch data,        setup events, refs etc...
      

 Characteristics of Components

• Reusability − Components are usually designed to be reused in different situations in different applications. However, some components may be designed for a specific task.
• Replaceable − Components may be freely substituted with other similar components.
• Not context specific − Components are designed to operate in different environments and contexts.
• Extensible − A component can be extended from existing components to provide new behavior.
• Encapsulated − A A component depicts the interfaces, which allow the caller to use its functionality, and do not expose details of the internal processes or any internal variables or state.
• Independent − Components are designed to have minimal dependencies on other components.

Make your components implement one task, be isolated, self-contained and encapsulated. This will make your components orthogonal, and any change you make is going to be isolated and focused on just one component. That’s the recipe for predictable and easy to develop systems.

 Study in detail the domain problem that your application solves, ask the client for a list of potential features. If you think that a certain place is going to change, then apply the orthogonal principle.

A key principle of a good design is the isolation of the logic that most likely will change: making it orthogonal. This makes your whole system flexible and adaptable to change or new features requirements.

If the orthogonal principle is overlooked, you risk creating components that are tightly coupled and dependent. A slight change in one place might unexpectedly echo in another place, increasing the cost of change, maintenance and creating new features.

Are your UI components accessible?

Summary (tl;dr)

When auditing your page's UI components for accessibility, ask yourself:

• Can you use your UI component with the keyboard only? Does it manage to focus and avoid focus traps? Can it respond to the appropriate keyboard events?
• Can you use your UI component with a screen reader? Have you provided text alternatives for any information which is presented visually? Have you added semantic information using ARIA?
• Can your UI component work without sound? Turn off your speakers and go through your use cases.
• Can it work without color? Ensure your UI component can be used by someone who cannot see colors. A helpful tool for simulating color blindness is a Chrome extension called SEE, (try all four forms of color blindness simulation available). You may also be interested in the Daltonize extension which is similarly useful.
• Can your UI component work with high-contrast mode enabled? All modern operating systems support a high contrast mode. High Contrast is a Chrome extension available that can help here.

Think All Above Topic When You Create New Component in any language or framework or library