Bad practices to avoid in Angular

Here we have gathered a list of bad practices to avoid when you are developing an Angular application. Before starting a new project it's highly recommended to make a similar list based on your previous experience, it will help to learn the lessons and to not redo the same errors again and again. nested logic structures

  • lack of clear design pattern such as container/presentational components results in hard to read, debug, test and maintain codebase. Also called smart/dumb components, this pattern should be used everywhere in the app.
  • lack of application monitoring and error tracking at the beginning of the project such as sentry. It results in a tons of bugs the day you install it and then you have to work for months in order to clear the app of all the bugs.
  • lack of pure functions, the developers are used to write impure functions which are changing the state of the component variable inside the function, this results in side effects and function are not testable. It's harder to write pure function but it results in easier to maintain code.
  • lack of simple typings in objects, functions, inputs and outputs, developers sometimes use any instead. if in addition you don't have unit tests then your code it's very vulnerable to errors.
  • lack of readonly and deepreadonly typings it results in unsafe code and possible mutation of any attributes in the codebase, functions will have potentially side effects.
  • lack of clear pattern for overriding the existing theme. A clear convention should be used, for instance if you want to override material, there are many different cases to know: (theming variables, overlay components, regular components...) you must check the articles written by razroo called customize Angular material design.
  • lack of splitting in modules, especially lazy modules, it will results in big main bundle but also it will makes the app more and more coupled and later it will be almost impossible to split the codebase in lazy modules.
  • wrong usage of ngrx, indeed this library should be used only for a certains types of entities which are shared, hydrated, available, retrieved, impacted. That's also why in 2020 multiples new solutions emerged in order to give developers the ability to store data in a local state instead of the global ngrx state.
  • usage of ::ng-deep without :host is going to affect the css of the others components, the style isolation principle is broken, the way to avoid that is by using :host ::ng-deep or even better to use CSS variables to override the style as explained in our best practices guide. Those errors are also due to the fact that angular material must render part of the components outside of the components, that means there is a overlay panel detached which pop on top of the view, for instance when mat-select is open.
  • accumulation of circular dependencies warnings will make your app less and less maintenable. Each time you detect a circular dependencies it's recommended to take time and fix it.
  • Using combineLatest in an NgRx effect will cause problems triggering unexpected actions in your application. It is strongly advised to use withLatestFrom or at worst forkJoin in order to be sure that you are not going to listen to future events.
  • usage of scss deprecated imports in each components produces a lot of duplicated code.

Learn more about Angular

Learn reactive programming with rxjs .