Design guidelines ITE [architect]

posted in: architect, Standards | 0

Your Domain Specific Language (DSL) is your Model/s Core API in pure Javascript. This is to avoid requiring too much knowledge of the framework itself before being able to contribute. Focusing on JavaScript also offers some protection against investing too heavily in framework-specific knowledge.

Keep your app logic in the Models and Flow and Interaction logic in your HTML with AngularJS. Having to write application logic inside of a template feels like a violation of separation of concerns. It has some short-term payoffs and can make simple things really easy. However, when you want more control it can be difficult to do within the constraints of the framework.

No monolithic, do-everything widget frameworks. These often make lots of assumptions about how you want to structure your HTML and often violate separation of concerns.

Model state is completely decoupled from view state. Again, this is to separate concerns.

You should not have to be a JavaScript rockstar to edit templates. Templates in separate files with very little logic allows designers to edit templates without having to know how everything works.

The DOM is simply a view of the state and reacts to changes in the model layer.

Simple, decoupled file structures with lots of components that solve one problem each.

As little magic as possible.

People who already know JavaScript should be able to work on the app without lots of knowledge about a specific tool or framework.

The inverse of the previous point should also be true in that people who learn how the app works, should accidentally learn how JavaScript works in the process.

It should play nicely in a team environment using version control (no giant files).

Every piece of functionality should have an obvious “home.” Structure, structure, structure. This makes it easy to jump into old code to fix bugs or to jump from project to project.

The project should have a set of code style standards that are enforceable by an automated process. This encourages readability and consistency throughout the codebase. It centralizes code style arguments around an enforceable standard. We find that this minimizes a lot of back-and-forth about code style because it becomes a simple automated pass or fail.

It should be flexible enough to really be able to build anything you want without sending a bunch of unused code to the browser.

Leave a Reply