There is more to developing a component than making sure the component looks and works the way it should. Components are a huge portion of what our SPA is made up of so we should consider each component's performance, usability, readability, and more. This will help make sure our code stays maintainable and performant over time.

Performance 🏃

For the user's sake, we want the component to be as performant as it can be. The SPA's job is to quickly render the data provided by the backend systems. Achieving this can be supplemented with built-in Angular performance features, and thinking about how the DOM is made up.

1. Use trackBy along with your ngFor directives.
   This will tell Angular what to consider as a "change" in our object being iterated so that it does not re-render the entire iterable to the DOM.

2. Use ChangeDetectionStrategy.OnPush when applicable.
   This strategy is intended to be used with components with immutable reference types. It will turn off the component's expensive automatic change detection. Make sure to check whether the component is still working as intended after this. If the inputs received from the parent component are mutated in the parent component, the component using OnPush will not update because it is not receiving a new reference of the input.

3. Watch out for DOM over-pollution.
   It is good to consider how your component is going to affect the structure of the DOM. For example, if items produced by a loop need an associated modal component for each, do not include the modal within the items. That would make an unnecessary amount of modals in the DOM. Rather, have the modal component live at the same level as the items (or somewhere else that makes sense), and have the items emit an output that is used to open/populate the singular modal.

4. Make sure to unsubscribe from your Observables in ngOnDestroy.
   If subscriptions are not unsubscribed from when the component is destroyed, a huge memory leak occurs because the callback attached to the subscription will be continuously called. Memory leaks take from resources and slow down the application.

Usability 🔨

For the developer's sake, we want components to be easy to use. The closer to a "plug and play" component the better.

1. Avoid speculative generalization.
   Most of the time, we want to find the sweet spot between a one-off and an overly abstracted component. Component features should be written to handle most cases, not all cases all of the time. Make sure you're not overly abstracting a component for cases it may probably never be used for.

2. Think about how the component will be consumed.
   What will be needed for the inputs/outputs? Much like the point above, the goal here is to find a good middle ground between simplicity and flexibility. Don't include inputs/outputs that are not needed, the component can always be extended to include new ones later. Also, do not include too little nor too many inputs/outputs that it makes the component hard to use.

3. Provide the component in the correct module.
   Make sure components are provided at the correct scope. If it's going to be a shared component throughout the app, we'll want to provide it at a higher level. If it will only be used in a certain module, make sure the scope is to that module. This will help us keep our codebase maintainable, and keep our build times low. Remember that each time you make a change to a component, the module that the component belongs to will need to be built again.

Readability 📘

When developing Angular components, they should use the same practices as other components within the codebase. Following common practices helps other developers build a rough mental model of components at first glance, which makes them easy to read. When components are easier to read, they're easier to maintain, debug and extend.

1. Structure the component correctly.
   Placement of your imports, types, enums, markup, properties, methods, etc. matter. This may also include alphabetical order, or public/private order. Make sure the component being developed is following the same patterns as the other components in the codebase. Do the same for external files as well, such as external styling sheets.

2. Follow style guidelines.
   Components should be written using common style guidelines. Everyone writes code a bit differently, so these guidelines help us keep things manageable. This helps our team write code that we can all easily and quickly understand.

3. Consider splitting the component into child components.
   Child components should be created when their markup bloats the parent component, or when the parent component has a chunk of state/logic that would make sense being kept separate in a child component.

Misc. 🌀

1. Consider implementing accessibility and responsiveness solutions to the component.
   Think about the contexts that the component will be used in. Who is using it? What display sizes will this component be used on? Areas of accessibility that should be thought of are visual, hearing, cognitive, and motor. When thinking about responsiveness, gauge whether this component will need to take another shape as screen sizes get small or large.

2. Research older components to see how they handled similar cases to the component you are building.
   Most of the time, components share similar logic in certain areas. Take a look around when developing a component to see what others have done to solve certain problems. You may be able to use some of their ideas, or make them even better. Doing this can be a good opportunity to reinforce your ideas, or learn something new.

Add to the discussion below if you've got any others to add! :)