WIP: route to component

Author: christopherthielen

_guide/105.ng1-route-to-component.md

@@ -6,6 +6,77 @@ sitemap: true
 permalink: /guide/ng1/route-to-component
 ---
 
-{% include toc classes="collapsible" icon="columns" title="Route to Component" %}
+{% include toc icon="columns" title="Route to Component" %}
+
+UI-Router for Angular 1 version 1.0 introduced the ability to route directly to 
+[Angular 1.5+ components](https://docs.angularjs.org/guide/component).
+
+Although UI-Router has always allowed views to be defined as arbitrary `template` and `controller` combinations, we
+highly recommend that the Angular 1.5 component model is adopted instead.  
+
+In this guide, we'll cover how to route to Angular 1.5 components and how to supply them with resolve data.
+
+
+# Angular 1.5 .`component()`
+
+An Angular 1.5 component is a reusable piece of a web page, which encapsulates both markup and behavior.
+A component is self-contained; it does not access `$scope` values from parent elements, nor does it provide values on `$scope` for children to access.
+A component gets all its input data from a parent component as explicit property bindings via attributes in the parent's template.
+Any outputs (for communication to the parent) is done using event callbacks, also via attributes in the parent template.
+
+In addition to inputs and output bindings, a component also has lifecycle hooks.
+
+The component model from Angular 1.5 aligns closely with the component model from Angular 2.
+From a high level, it even has much in common with even React's or Web Component's models.
+This level of parity between frameworks allows you to reason about application structure in a similar way, no matter what framework you are using.
+{: .notice--info}
+
+To learn more about Angular 1.5 components, refer to the [official docs](https://docs.angularjs.org/guide/component)
+and read a [blog or two](https://www.google.com/search?q=angular+1.5+component+blog&oq=angular+1.5+component+blog).
+
+# UI-Router Legacy
+
+UI-Router applications are defined as a tree of states.
+Each state typically has one or more views.
+
+In legacy UI-Router, the only way to define a view was to provide a `template` and a `controller`.
+The `template` provided the DOM layout, while the `controller` injected services and resolve data, and implemented logic required to make the view work.
+
+A typical legacy (non-component) state definition might look like this:
+
+```js
+.state('fooState', {
+  url: '/foo/:fooId',
+  resolve: {
+    fooValue: function($stateParams, $http) {
+      return $http.get('/api/foo/' + $stateParams.fooId)
+          .then(function(resp) { return resp.data; });
+    }
+  },
+  template: '/partials/foo.html',
+  controller: 'FooController'
+});
+```
+  
+Where `fooController.js` is: 
+
+```js
+.controller('FooController', function(fooValue, $scope) {
+   $scope.foo = fooValue;
+});
+```
+
+And `/partials/foo.html` is:
+
+```html
+<h1>{{ foo.name }}</hi>
+<ul>
+  <li ng-repeat="bar in foo.bars">
+    
+    {{ bar.name }}
+  </li>
+</ul>
+```
+
+
 
-## Coming soon...