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 

Angular Template Syntax and NgClass & NgStyle Directives

	<!-- Native Class and Style Attributes -->
	<input class="is-danger my-button" style="border: none; color: blue">
	<!-- Angular class and style Bindings -->
	<input [class.is-danger]="booleanProp" [style.border]="borderProp">
	<!-- ngClass -->
	<input [ngClass]="{'is-danger': booleanProp, 'myButton': true}">
	<input [ngClass]="isDangerButton">
	<!-- ngStyle -->
	<input [ngStyle]="{'border': borderProp, 'color': colorProp}">
	<input [ngStyle]="hasColorBorder">
	<!--
	booleanProp, borderProp, etc...
	would be properties from our
	Typescript class
	--> NgClass NgClass can receive input via inline declarations, or a property/method from our TypeScript class. This can make the syntax feel more convoluted than it really is. Ultimately, NgClass can take the following as input: A space-delimited String [ngClass]="is-info is-item has-border" An Array of Strings [ngClass]="['is-info', 'is-item', 'has-border'"] An Object [ngClass]="{'is-info': true, 'is-item': true} All of the above examples are inline and could be replaced with a Typescript property/method as long as the expression returns valid input: export class MyComponentClass { myStringProperty = "is-info is-item has-border"; myArrayProperty = ['is-info', 'is-item', 'has-border']; myObjectProperty = {'is-info': true, 'is-item': true}; } [ngClass]="myStringProperty" [ngClass]="myArrayProperty" [ngClass]="myObjectProperty" Key Points We can pass a Typescript property/method or write an expression inline to our NgClass Directive NgClass can take a String, Array of Strings, or Object Expression as input. Under the hood, NgClass is adding/removing classes via Renderer2 addClass() and removeClass() NgClass appends, it does not overwrite. NgStyle NgClass and NgStyle share a significant amount of functionality and behavior. The key difference is: NgStyle takes a key-value pair object as input. NgStyle applies styles and not classes. NgStyle will overwrite styles defined by the native style attribute. Syntax NgStyle takes a key-value pair object, where the key is a CSS style. An optional suffix can be added to the key, making keys such as this viable: [ngStyle]="{font-size.px: 16}" Instead of [ngStyle]="{font-size: 16px}" Similar to NgClass, NgStyle can be passed input inline or use a Typescript property/method. [ngStyle]="myObjectExpressionProperty" Key Takeaways NgStyle can accept a key-value pair as input, where the key is a valid CSS Style NgStyle can be passed input via inline or a Typescript property or method NgStyle under the hood utilizes Angular’s Renderer2 to invoke setStyle() and removeStyle() NgStyle will overwrite existing styles on the element.