# Creating Components
> Components are classified as a self contained collection of the view layer. 

## Isomorphism
This usually comprises a single React Component and it's associated LESS definition. The connection between the two is handled by webpack during the compilation step through an ```import```:

```javascript
import './my-less-file.less';
```

## The ModelListener
The ModelListener module is available in the es6 branch of dd. It's a thin layer that connects the dirty flag callbacks of a Model to a React Component's lifecycle methods and not much else. Whenever a component contains a data layer (which is usually the defining factor between an atom and a component), you should extend off of the ModelListener instead of React.Component. This ensures that the view is updated whenever your data model changes. Some experiments involved this layer manipulating the component's state directly, but this proved fraught with locking problems and required a lot of cognitive load on the developer to understand when they were using the data model and when they were using the built in view state to mitigate drawing errors. Instead, a clean separation is provided between ```this.state``` and ```this.model```. All ModelListeners follow a basic format:

```javascript
import React from 'react';
import ModelListener from 'dd/lib/model-listener';
import AModelClass from 'models/a-model-class';

class View extends ModelListener {
	static defaultProps: {
		model: AModelClass
	}

	render() {
		return <div>{ this.model.name }</div>;
	}
}

export default View
```

This ```View``` has a data representation of ```AModelClass```. Within the class' ```defaultProps```, the model should be defined. This leverages React's built in default property fallback to help with the reusability of components that are released in different contexts. Sometimes the ```View``` instance will be a child node of another component, and it's model will be passed down from the parent through the model property. In other cases, where ```View``` will be instantiated as the root element, it'll create it's own data hierarchy that the ```View``` instance interacts with.

## When to use models and when to use state
###### *or why fat models are the best*
In most cases, you're going to want to default to using the model. The discussion on the split between the data and the view layers can sometimes feel esoteric, as it's inevitably a talk on the intrinsic nature of an object, but a good rule of thumb is that any data that *can* exist without the view, *should*. The street name of an address, or the make and model of a car; these are properties of the data *model*. If the widget is in a loading state or not, or the number of times a button has been pressed; these are properties of the *state*. By removing the data from the view, we can reuse it in all over our code base. Whether it's being filled from an API call, or loaded from Local Storage, or populating the DOM, we can use the model as a consistent data contract between all the disparate pieces of the code base. Helper functions then also follow the data within it's context. If you have a user object, and are always having to determine the logic for how to display their name from a combination of first, last, email, and phone number, just create a ```displayName``` function on your user model and have it immediately available in all of your views.
