问题
I've been looking around behind the logic of when someone shall create a new component in a web application on angularjs / angular but I suppose this is more general and might apply on all component based front end frameworks.
I know that there are some principles like it should be abstract and reusable but e.g. I have seen on angular docs that each separate route looks at a specific component (how can this be reusable). Is there any solid question which I might ask before creating a new component ?
回答1:
In order to make a decision whether you have to create a component or not, i think you have to answer the following questions:
- Is it possible for your code chunk to be reused? If yes, construction of a new component seems like a great idea.
- Is your code quite complex? If yes maybe its good idea to split in separate components in order to make your code more readable and maintainable.
回答2:
This advice applies regardless of framework. A new component is typically made for one of two reasons:
(1) Resuability
You will re-use this component. Re-use levels vary. Some code may be project specific but may be used in 2 places in your project but would never be used outside your project. It's still re-use.
However, if it's a highly re-usable piece of code you should really refine it and maybe publish it to the world!
(2) Organisation
Sometimes code may go on too long. There might be hundreds of lines and its just unreadable. Breaking that code down into components can aid readability and code organisation. Here, the new components should be child components of the parent.
Code structure:
You should consider placing highly reused components in a folder called components. The kind of component that could be made into / part of a third party library.
Project reusable components into a folder called apponents.
Finally, organisational components should be children of their parents and should be placed in a subfolder of their parent component.
回答3:
The longer I work with Angular, the more I think, within reason, the more components you can make the better. Certainly, there's the reusable factor, but I think they generally make your code more maintainable.
I don't use Ionic a lot, but it did shape my view on components quite a bit
<ion-header>
<ion-navbar>
<ion-title>Home</ion-title>
</ion-navbar>
</ion-header>
<ion-content padding>
<ion-list>
<ion-item *ngFor="let u of users">
<ion-avatar item-left>
<img src="{{u.ImgUrl}}">
</ion-avatar>
<h2>{{u.Name}}</h2>
<p>{{u.Status}}</p>
</ion-item>
</ion-list>
</ion-content>
They use components as often as you might be used to using bootstrap classes! But look how much more readable the code is. ion lists, have ion items. You generally can guess what an ion-avatar would look like, but there could actually be several things going on inside the component. All of that is abstracted away. Complex things are broken down into small components that are easy to understand. Every component itself is generally simple.
For any html element, I think its worth considering what its point is and if it might be worth making into an angular component to make the code more compartmentalized and easier to understand from a high level.
回答4:
Follow the steps before you decide to write a new component,
(i) Identify the responsibility - You should define a components responsibility before writing it therefore you know when you start writing.
(ii) When it is large - As a rule of thumb if your component code goes beyond 600 lines , divide into smaller components which makes your code easy to read and maintain
(iii) When you want to reuse - When you find a component being used in various modules, you should make it a shared component.
The above 3 rules will make help you to identify when you need to write a new component. Hope it helps
回答5:
What you providing to a Route is actually a view/container but this is not really a famous term in Angular so we just refer to it as a Component.
View/Containers
These are actually the components passed to the Route and the parents of all components for a route. They are connected to the store and pass down the data to the components (most of the times). These are not reusable and specific to a route. They are just a component that combines all the smaller components to create a route.
It is preferred that components are reusable and dumb. By dumb, I mean components that just receive data and show it and are not directly connected to the store.
In AngularJS there are only components but in React there are containers/views and components (even though in the code they all look the same). In most of the react projects, you will find that there are different directories for views and components.
So you are actually right that components that they should be reusable and abstract. What you are confused about is between views and components. I wish these terms were popular in the Angular world too.If you find that a particular component is not worthy of being separate let it be part of the View.
回答6:
From React docs:
But how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the single responsibility principle, that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That's because UI and data models tend to adhere to the same information architecture, which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.https://facebook.github.io/react/docs/thinking-in-react.html
PS. Also think about performance. By separating components you can manage the lifecycle of small pice of view, so basically if your component shows a single (atomic) part of data, you can easily define when component should update. see shouldComponentUpdate().
来源：https://stackoverflow.com/questions/46192426/how-to-tell-when-to-create-a-new-component