Directives in AngularJS are an exemplary solution for writing reusable
components in modern web applications. They allow us to encapsulate all the
messy business logic and expose a very clean, declarative interface to consumers
of the API. As with most tools for constructing abstractions, however,
directives have certain limitations that can lead to implementation details
leaking through, resulting in code that less
and, consequently, less maintainable.
There are, however, ways to work around these shortcomings and to build
simpler, more expressive interfaces to our directives. Leveraging a lesser known
logic. This method is also well suited for building on top of third party
directives with a complex API by abstracting the details into a business
object. In doing so, our markup will become more in line with the ideal in
promotes declarative code
over imperative. Without further ado, let us look at the current situation and
how we can improve our directives.
Motivation and Background
In the process of writing larger applications in
I find it far too easy to initially focus on one small part of the problem
while losing perspective on the bigger picture. For instance, I will begin by
rendering a simple scene, followed by splitting out components, and finally
adding in signals. While this is generally a good approach, in my mind,
it is sometimes difficult to retrofit patterns onto the basis of the application
I have already written.
There are some really excellent resources covering the architecture of applications
in the Elm language. The
on the subject can be found on the official Elm site and covers everything at
a high level. The best example is likely
ported to Elm which uses many the concepts from the article to create a rich
and simple interface, showcasing just how powerful Elm is. Another great and
extremely polished example is
which also incorporates the separation of components as outlined in the original
In this article, we will walk through the steps for writing an implementation
Conway's Game of Life
Elm programming language.
In doing so, we will learn about the basic principles involved with writing
programs in Elm, while grounding them in a concrete problem. We will be
building a single program in steps, so much of the source will be repeated
between the examples, but it will be more clear to present each step in its
I first became interested in Elm after seeing Evan Czaplicki's
mloc.js 2013, where he presented an overview of Elm and the compelling example
of how one would write a simple side-scroller in an extremely straight forward
fashion as a consequence of the core concept in Elm: signals.
Lazy Evaluation and Recursive Lists
In Haskell, it is possible to construct infinite lists via recursive
definition. This is only possible because Haskell uses
rather than eager evaluation. Otherwise, the entire list would need to be
calculated and the program would never terminate.
Because Haskell makes it easy to define lists and is lazy, the code for
defining an infinite series is very simple. The following list represents
the fibonacci sequence.
Sometimes when working with nested scopes, you may encounter a situation in
which some scope action depends on the status of some arbitrarily nested
controller. This could be a multi-part form built from reusable components,
preventing the user from proceeding until complete, for example.
An architecture that allows scopes nested within another scope to influence the
life cycle of the latter has one primary advantage, namely, greater separation
of concerns. A nested controller can supply functions for data validation and
formatting, while the parent controller defines functions for navigation and
accumulation of results. This leads to better modularity, as the parent
controller is isolated from the implementation of nested controllers, while the
latter are able to be used modularly in more contexts.