When to Create a Component: Finding the Right Cut In short: A component is not a way to shorten a long HTML file. It is a way to give one job one owner. If you cannot name the job in a sentence, you are not ready to cut. In the last lesson we saw that Angular components are living blocks — each with its own instance and view, arranged in a tree. Now comes the question everyone hits next: when exactly should I make a new one? The common trap is thinking components are about file length. They are not. Let's look at how to draw sensible boundaries. What makes a good component Create a component when a piece of your screen has a clear, coherent responsibility. A good component owns three things: 1. The look — its markup and its own styles. 2. Local behaviour — opening a dropdown, highlighting a selection, managing keyboard focus. 3. Communication — the data it needs, and the events it reports back to its parent. You are building a tool to assign drivers for the morning milk run. You make a . This is a good boundary because of what each side does not need to know: The parent page has no idea how the menu animates open or filters its search list. The menu has no idea which database to update after a truck is chosen. It shouts "Truck 4 was selected!" and lets the parent do the work. The reusability myth There is a widespread belief that you should only create a component if you will use it more than once. This is false, and it leads to enormous page components. A might be used exactly once in the entire application. It is still a good component, because it is the coordinator for that screen: it pulls the day's totals, arranges the layout, and manages the children inside it. Other good reasons to cut: It is a section your team already talks about by name ("the region sidebar"). It has fiddly internal logic — a date picker, a capacity calculator — that you want to test on its own. Wrapping it makes the parent readable. Smart parents, simple children Keep business rules in parents and presentation rules in children. A manager tries to dispatch a tanker that has not reached its minimum load. The parent page owns the rule: is a half-empty tanker allowed to leave? The child owns the dialog. The dialog knows nothing about milk volumes or company policy. Its only job is to show a message, block the user when told to, and report the click. Because that job is so small, the same dialog later confirms deleting a user account without a single change. When not to extract Do not create a component because a block of HTML runs to twenty lines. If a section just prints a static list of contact numbers for a regional centre, leave it in the parent. Every unnecessary component adds inputs to wire, outputs to route, and a file to open when tracing a bug. The test: can you describe this piece of UI's job in one plain sentence? If yes, cut. If your sentence needs an "and" in the middle, you are probably cutting in the wrong place. "But I thought splitting components always improves performance" This one sounds obviously true, especially now that is the Angular 22 default. Smaller components, smaller check units, faster app. Right? Only if the split follows the data. Change detection granularity is decided by where state changes , not by how many files you have. Consider a centre card split into four child components, where the parent passes the same object to all four: When one litre count changes, becomes a new object, all four inputs get a new reference, and all four children re-render. You have four files, four sets of inputs, and exactly the rendering cost you had with one component — plus the overhead of four instances. The version that actually helps passes only what each child reads: Now a litre change re-renders and nothing else, because the other inputs are primitives that did not change. The belief is reasonable — it just skips a step. Splitting components helps when it narrows what each child depends on . Splitting while handing every child the same god object is filing, not architecture. Cheat sheet Situation Cut a component? --- --- Has its own local UI state (open/closed, focused item) Yes Your team already has a name for it Yes Tricky logic you want to test in isolation Yes Used once, but coordinates a whole screen Yes 20 lines of static markup, no behaviour No Purely to shorten a file No You would pass it the entire parent object anyway Not yet — narrow the data first Recap It is about ownership, not file size. A component gives one visible job one owner. Reuse is not the only reason. Single-use coordinator components are good design. Parents hold business rules; children hold presentation. The dialog reports the click; the page decides what it means. Splitting only speeds things up when it narrows each child's data. Passing the same object to four children buys you nothing. If you cannot say the job in one sentence, do not cut yet. Next: how templates turn that state into pixels — and the logic that must never live in…