Angular - 3 2 Planning an application
Before writing a single line of code, we sit down and plan the structure of the application. Sketching the future component tree and listing the data we are going to handle takes only a few minutes but pays back massively during implementation. Plans are rarely perfect: components will be added, merged or moved as we go, yet starting with a solid foundation prevents the kind of cargo-cult coding that spirals out of control.
Every Angular application starts with a single root container — the AppComponent. Think of it as a wardrobe holding all the drawers: each feature lives in its own drawer, but they are all stored in the same root. Because the app has two distinct sections (shopping list and recipe book) it makes sense to introduce a dedicated header component that handles the navigation between them. The header will later hold a small dropdown to save and load data from the server, so isolating it as its own component is the right call.
Components we will need
- HeaderComponent — navigation between the two sections and a management dropdown.
- ShoppingListComponent + ShoppingEditComponent — list of ingredients and the edit form to add or update items.
- RecipesComponent wrapping RecipeListComponent, RecipeItemComponent and RecipeDetailComponent — the master/detail recipe view.
Each of these components is responsible for one job: displaying a list, showing details, editing a single entry. Keeping them small and focused makes them easier to test and reuse. Splitting can always go deeper, or be merged, depending on how the implementation feels.
The last thing to think about up front is the data model. The application clearly needs an Ingredient class (with a name and an amount) shared between recipes and the shopping list, and a Recipe class with a title, a description, an image and a list of ingredients. Defining these classes early gives every component a clear contract for the data it produces or consumes, which becomes critical the moment components start exchanging information through services. With this rough plan in hand we can finally jump into the next lesson and create the project itself.
Summary
This lesson teaches how to structure and plan an Angular application before building it. The instructor walks through a practical example of a shopping list and recipe book application, showing how to identify necessary components (root component, header, list components, detail components) and organize them hierarchically. While applications inevitably change during development, careful upfront planning provides a solid foundation and prevents working without clear direction.
Key points
- Define your application structure and components before coding, even though changes will naturally occur during development
- Use a hierarchical component architecture with a root app component as the main container holding all feature components
- Separate concerns by assigning each component one primary responsibility: displaying lists, showing details, or handling editing
- Externalize components with business logic (like headers) from the root component to keep it focused on overall structure
- Plan data models early and clearly define how entities like ingredients, recipes, and shopping items will be structured
- Be flexible during implementation—components may be merged, divided, or added differently than initially planned
FAQ
Will my initial component plan always be correct?
No. Applications naturally evolve during development—you may add unexpected components, merge planned ones, or restructure based on implementation experience. However, having a solid upfront plan prevents chaotic development and provides a reliable foundation.
Why create a separate header component instead of hardcoding it in the app component?
Because the header contains its own business logic (navigation, routing, recipe data management). Externalizing it as its own component keeps the root app component clean and focused solely on maintaining overall application structure.
What order should I follow—plan components first or data models?
Start by identifying your application's features and the components needed to display them, then define your data models. This ensures your structure aligns with the actual information your components will manage.