While this decision allows better API discoverability, the trade-off is that we're largely giving up on custom constraints and behavior. For example, if we wanted to change the application to make the list be persisted, a native Array would most certainly not be a suitable class to use.
In order to deal with that type of refactoring, one can explicitly decide to support only a subset of the Array API, and implement another class with the same interface as this subset API.
Given the code above, the replacement class would only need to implement the .push() and .map() methods. By freezing APIs and swapping implementations, the developer can completely avoid touching other layers in the application while refactoring.
todo.Todo = Array;todo.TodoList = Array;becomes:
-todo.Todo = {
- push: function() { /*...*/ },
- map: function() { /*...*/ }
+todo.TodoList = function () {
+ this.push = function() { /*...*/ },
+ this.map = function() { /*...*/ }
};
Hopefully these examples give you an idea of ways requirements can change over time and how Mithril's philosophy allows developers to use standard OOP techniques to refactor their codebases, rather than needing to modify large portions of the application.
diff --git a/archive/v0.1/mithril.min.zip b/archive/v0.1/mithril.min.zip
index 74e7ba54..632a3527 100644
Binary files a/archive/v0.1/mithril.min.zip and b/archive/v0.1/mithril.min.zip differ