Merge pull request #242 from Whoaa512/m.module-return-controller

M.module return controller

docs/mithril.module.md

@@ -70,13 +70,13 @@ The example below shows a component module called `user` being included in a par
 var dashboard = {
 	controller: function() {
 		this.greeting = "Hello";
-		
+
 		this.user = new user.controller();
 	},
 	view: function(controller) {
 		return [
 			m("h1", controller.greeting),
-			
+
 			user.view(controller.user)
 		];
 	}
@@ -155,7 +155,7 @@ module1.controller = function() {
 [How to read signatures](how-to-read-signatures.md)
 
 ```clike
-void module(DOMElement rootElement, Module module)
+Object module(DOMElement rootElement, Module module)
 
 where:
 	Module :: Object { Controller, void view(Object controllerInstance) }
@@ -166,19 +166,19 @@ where:
 -	**DOMElement rootElement**
 
 	A DOM element which will contain the view's template.
-	
+
 -	**Module module**
 
 	A module is supposed to be an Object with two keys: `controller` and `view`. Each of those should point to a Javascript class constructor function
-	
-	The controller class is instantiated immediately upon calling `m.module`.
-	
+
+	The controller class is instantiated immediately and a reference is returned upon calling `m.module`.
+
 	Once the controller code finishes executing (and this may include waiting for AJAX requests to complete), the view class is instantiated, and the instance of the controller is passed as an argument to the view's constructor.
-	
+
 	Note that controllers can manually instantiate child controllers (since they are simply Javascript constructors), and likewise, views can instantiate child views and manually pass the child controller instances down the the child view constructors.
-	
+
 	This "[turtles all the way down](https://en.wikipedia.org/wiki/Turtles_all_the_way_down)" approach is the heart of Mithril's component system.
-	
+
 	Components are nothing more than decoupled classes that can be dynamically brought together as required. This permits the swapping of implementations at a routing level (for example, if implementing widgetized versions of existing components), and class dependency hierarchies can be structurally organized to provide uniform interfaces (for unit tests, for example).
 
 

mithril.d.ts

@@ -5,7 +5,7 @@ interface MithrilStatic {
 	(selector: string, children?: any): MithrilVirtualElement;
 	prop(value?: any): (value?: any) => any;
 	withAttr(property: string, callback: (value: any) => void): (e: Event) => any;
-	module(rootElement: Element, module: MithrilModule): void;
+	module(rootElement: Element, module: MithrilModule): Object;
 	trust(html: string): String;
 	render(rootElement: Element, children?: any): void;
 	render(rootElement: HTMLDocument, children?: any): void;

mithril.js

@@ -457,6 +457,7 @@ Mithril = m = new function app(window, undefined) {
 			modules[index] = module
 			controllers[index] = new module.controller
 			m.endComputation()
+			return controllers[index]
 		}
 	}
 	m.redraw = function(force) {

tests/mithril-tests.js

@@ -34,20 +34,21 @@ function testMithril(mock) {
 		mock.requestAnimationFrame.$resolve()
 
 		var root1 = mock.document.createElement("div")
-		m.module(root1, {
+		var mod1 = m.module(root1, {
 			controller: function() {this.value = "test1"},
 			view: function(ctrl) {return ctrl.value}
 		})
 
 		var root2 = mock.document.createElement("div")
-		m.module(root2, {
+		var mod2 = m.module(root2, {
 			controller: function() {this.value = "test2"},
 			view: function(ctrl) {return ctrl.value}
 		})
 
 		mock.requestAnimationFrame.$resolve()
 
-		return root1.childNodes[0].nodeValue === "test1" && root2.childNodes[0].nodeValue === "test2"
+		return (root1.childNodes[0].nodeValue === "test1" && root2.childNodes[0].nodeValue === "test2")
+			&& (mod1.value && mod1.value === "test1") && (mod2.value && mod2.value === "test2")
 	})
 
 	//m.withAttr