Using Defined Properties for Better AngularJS Directives

On Directives

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 DRY 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 feature of JavaScript, we can encapsulate additional details of our business 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 AngularJS, which promotes declarative code over imperative. Without further ado, let us look at the current situation and how we can improve our directives.

Continue reading

Barebones Architecture in Elm

Motivation and Background

In the process of writing larger applications in Elm, 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 canonical article on the subject can be found on the official Elm site and covers everything at a high level. The best example is likely TodoMVC (source) 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 Dreamwriter (source), which also incorporates the separation of components as outlined in the original article.

Continue reading

Writing Game of Life in Elm

Introduction

In this article, we will walk through the steps for writing an implementation of Conway's Game of Life in the 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 entirety.

I first became interested in Elm after seeing Evan Czaplicki's talk from 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.

Continue reading

Lazy Ruby

Lazy Evaluation and Recursive Lists

In Haskell, it is possible to construct infinite lists via recursive definition. This is only possible because Haskell uses lazy evaluation 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.

Continue reading

Hooks in AngularJS Controllers

The Situation

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.

Continue reading