Design Principles

Page under construction

---

Having a couple of principles to follow under ongoing development is one way to set a standard of quality, a degree of maintainability, and reduce 'surprises' within the codebase. In this page I indicate the principles I've strived to follow here. Of course these are not definitive; as is the case for any rule or principle. BUT, violations to these principles should be documented to reduce friction while reading code.

Modularity

Whenever development is in place, it should be easy to figure out where to place new code. Angular allows development and organization by use of building blocks called modules, which in Trébol frontend case, results in two feature modules and a shared module:

• store module holds all interfaces accessible by the public as a whole (that is, the customers of the store)
• management module has interfaces that only employees can access and use

Components vs Services

Components are to Angular as Views are to the MVC design pattern. Thus, Components should be prepared to receive data and display it, as-is, without alterations. They must be introduced inside HTML templates or invoked through calls to specialized Angular services. On the other hand, Services can act as any of two other sides of the MVC design pattern. And they can be injected and reused many times. Whenever logic is involved, a service should be in place to execute it.

Components should not have Trébol API services directly injected into them; instead a single middle-man (aka Controller) service should have them injected instead, and the component should depend only on that service.