(I'm an Angular dev that cares about code quality and will provide my opinion of what makes a good component, from a mix of a few articles and from some experience 😄)
TLDR: There is no such thing as a "good component" in general, its all based upon what your doing, but smaller is usually better.
I'd say there are 2 types of components:
Smart/view/top-level components - These have the core business-logic, and potentially some state. They delegate what is happening on the page, and can be considered more like "views". Do not try to re-use this component, instead delegate its logic to other entities that can be re-used. (In Angular you'd use directives, pipes, and services to handle shared logic)
This component could get large, but you want to delegate to other entities as much as possible, leaving just "big picture" stuff to this component. These entities could be external functions/helper-classes or sub "smart" components.
You could create a smart component inside another smart component, but I'd only consider this for complex views with multiple parts that are separate. Generally you will run into issues communicating between smart components that are "siblings", and this is where state-management solutions like Redux/ngrx come in, or solutions like React Hooks. If you don't use these solutions, I'd be very careful creating multiple sibling components without a solid game-plan on how to communicate between them.
Dumb/UI/presentational components - These are your bread and butter components. In a perfect world all your UI is handled by UI components with your smart components just passing data(this is my opinion 😉). If the smart components handle big picture stuff, UI components should focus on the smaller things, like displaying data, inputting data, formatting data, etc.
They shouldn't have state, and should have little to 0 logic. These should be made with the idea of re-usability so they shouldn't know where they are in the app. You could compare these to pure functions (in React, components could be created from pure functions 😉)
The issues with these concepts is its hard to know which one to use most of the time, and handle all the edge cases. Its very easy to just make everything "smart", but then you end up having a hard time re-using anything.
You can't make all components dumb because you will eventually need some logic otherwise your app does nothing 😉
The key is to focus components, of any complexity, on primarily displaying data and managing minimal state. These sort of approaches are founded in a lot of state-management solutions, which pull away responsibility from the components themselves. (here's the motivation behind Redux) You should always strive to make all components simpler regardless of framework, or if your are or aren't using a state-management system.
Finally I want to point out as an Angular dev I can say an Angular component can be backed up by services (common logic, message passing), injection-tokens (customization via DI), directives (template logic) and pipes (template logic), which remove a number of use-cases from component logic.
I have limited knowledge of React, but do know JSX is far more flexible, so the presentation of complex UI is easier in React than it is for Angular. (no idea where VueJS stands here haha)
Keep things simple, and move logic out of components when and where possible. Isolate state out of components and most problems and complexity should go away. :)
(I'm an Angular dev that cares about code quality and will provide my opinion of what makes a good component, from a mix of a few articles and from some experience 😄)
TLDR: There is no such thing as a "good component" in general, its all based upon what your doing, but smaller is usually better.
I'd say there are 2 types of components:
This component could get large, but you want to delegate to other entities as much as possible, leaving just "big picture" stuff to this component. These entities could be external functions/helper-classes or sub "smart" components.
You could create a smart component inside another smart component, but I'd only consider this for complex views with multiple parts that are separate. Generally you will run into issues communicating between smart components that are "siblings", and this is where state-management solutions like Redux/ngrx come in, or solutions like React Hooks. If you don't use these solutions, I'd be very careful creating multiple sibling components without a solid game-plan on how to communicate between them.
The issues with these concepts is its hard to know which one to use most of the time, and handle all the edge cases. Its very easy to just make everything "smart", but then you end up having a hard time re-using anything.
You can't make all components dumb because you will eventually need some logic otherwise your app does nothing 😉
The key is to focus components, of any complexity, on primarily displaying data and managing minimal state. These sort of approaches are founded in a lot of state-management solutions, which pull away responsibility from the components themselves. (here's the motivation behind Redux) You should always strive to make all components simpler regardless of framework, or if your are or aren't using a state-management system.
Finally I want to point out as an Angular dev I can say an Angular component can be backed up by services (common logic, message passing), injection-tokens (customization via DI), directives (template logic) and pipes (template logic), which remove a number of use-cases from component logic.
I have limited knowledge of React, but do know JSX is far more flexible, so the presentation of complex UI is easier in React than it is for Angular. (no idea where VueJS stands here haha)
Keep things simple, and move logic out of components when and where possible. Isolate state out of components and most problems and complexity should go away. :)
extra reading:
Primary sources (framework docs):
reactjs.org/docs/hooks-intro.html
reactjs.org/docs/components-and-pr...
angular.io/guide/component-interac...
Secondary sources (blogs):
blog.angular-university.io/angular...
itnext.io/react-component-class-vs...
I didn't expect to have such a complete answer
Your comment is pure gold