<commit_before>Cosmos [![Build Status](https://travis-ci.org/skidding/cosmos.svg)](https://travis-ci.org/skidding/cosmos)
===
A foundation for maintainable web applications.

Cosmos glues [React](http://facebook.github.io/react/) components together and
creates a uniform relationship between them.

There's no such thing as *controllers* or *pages* in Cosmos, just *components.*
The UI is a tree of components consisting of a root component and its
descendants. Any component can be loaded full-screen as the root element and
a route is just an alias to component _props._

Check out [**Flatris**](http://skidding.github.io/flatris/), a demo app built
with Cosmos.

Jump to:

- [Manifesto](#manifesto)
- [Installation](#installation)
- [Specs](#specs)
- [Problem](#problem)
- [Contributing](#contributing)

## Manifesto

_cos·mos<sup>1</sup> `/ˈkäzməs,-ˌmōs,-ˌmäs/` noun — 1. The universe seen as
a well-ordered whole._

- Zero bootstrap
- Can be plugged into any other framework
- Everything is a Component
- Components are oblivious of ancestors
- Any component can be represented by a URI
- The state of the entire UI can be serialized at any given point in time
- Components can implement any data sync mechanism

## Installation

Either install the `cosmos-js` [npm package](https://www.npmjs.org/package/cosmos-js)
or include the build directly in your project.

```html
<!-- Development build -->
<script src="http://skidding.github.io/cosmos/build/cosmos.js"></script>
<!-- Production build -->
<script src="http://skidding.github.io/cosmos/build/cosmos.min.js"></script>
```

## Specs

In Cosmos, any component in any state can be represented and reproduced by a
persistent JSON. This goes hand in hand with React's declarative nature.

The input data of a component is a JSON object and the role of a component is
to transform its input data into HTML output. Easy to follow and assert
behavior. See [React Component](http://facebook.github.io/react/docs/component-api.html)
for in-depth specs.

### Core concepts

Reserved props when working with Cosmos: `component`, `componentLookup` and
`state`.

#### Component lookup

In order to make component definitions serializable, Cosmos doesn't work with
classes directly. The `component` prop holds the name of the component, while
the `componentLookup` prop is used for passing a mapping function that returns
corresponding component classes.

Working with the component lookup also results in cleaner component files,
especially when using CommonJS modules with relative paths.

```js
var myComponent = Cosmos.render({
  component: 'my-component',
  componentLookup: function(name) {
    // The component classes can be drawn from any global namespace or require
    // mechanism
    return require('components/' + name + '.jsx');
  }
});
```

#### Component snapshot

The props and state of a component can be joined into a unified snapshot. The
`state` prop holds the state of the component.

```js
// Alter the state of the component
myComponent.setState({isDisabled: true});

// Serialize the state of a component into a JSON object
var componentSnapshot = myComponent.generateSnapshot());
```

This is what `componentSnapshot` would look like:

```js
{
  component: 'my-component',
  state: {
    isDisabled: true
  }
}
```

#### State injection

Serializing the state of component is no fun if we can't load it back later.

```js
// The clone will be created with the identical state of the original component
var clonedComponent = Cosmos.render(componentSnapshot);
```



### Mixins

Core mixins are placed under the `Cosmos.mixins` namespace. Read more in the
[Mixins wiki page.](https://github.com/skidding/cosmos/wiki/Mixins)

## Problem

Most web frameworks start out clean and friendly, but at some point after you
go on to build a real-life application on them they stop cooperating and start
turning against you. Finding an honorable route for solving a problem is now a
luxury, workarounds are the norm.

This can happen over and over. Slick at first, unmaintainable in 2 years. But
why is that, why is complexity proportional to the number of features added?

Two reasons:

1. **Interdependence.** Tie a number of units together, rely on one to change
the state of another and you successfully gave birth to
an unpredictable ecosystem<commit_msg>Turn examples into continuous code #77<commit_after>Cosmos [![Build Status](https://travis-ci.org/skidding/cosmos.svg)](https://travis-ci.org/skidding/cosmos)
===
A foundation for maintainable web applications.

Cosmos glues [React](http://facebook.github.io/react/) components together and
creates a uniform relationship between them.

There's no such thing as *controllers* or *pages* in Cosmos, just *components.*
The UI is a tree of components consisting of a root component and its
descendants. Any component can be loaded full-screen as the root element and
a route is just an alias to component _props._

Check out [**Flatris**](http://skidding.github.io/flatris/), a demo app built
with Cosmos.

Jump to:

- [Manifesto](#manifesto)
- [Installation](#installation)
- [Specs](#specs)
- [Problem](#problem)
- [Contributing](#contributing)

## Manifesto

_cos·mos<sup>1</sup> `/ˈkäzməs,-ˌmōs,-ˌmäs/` noun — 1. The universe seen as
a well-ordered whole._

- Zero bootstrap
- Can be plugged into any other framework
- Everything is a Component
- Components are oblivious of ancestors
- Any component can be represented by a URI
- The state of the entire UI can be serialized at any given point in time
- Components can implement any data sync mechanism

## Installation

Either install the `cosmos-js` [npm package](https://www.npmjs.org/package/cosmos-js)
or include the build directly in your project.

```html
<!-- Development build -->
<script src="http://skidding.github.io/cosmos/build/cosmos.js"></script>
<!-- Production build -->
<script src="http://skidding.github.io/cosmos/build/cosmos.min.js"></script>
```

## Specs

In Cosmos, any component in any state can be represented and reproduced by a
persistent JSON. This goes hand in hand with React's declarative nature.

The input data of a component is a JSON object and the role of a component is
to transform its input data into HTML output. Easy to follow and assert
behavior. See [React Component](http://facebook.github.io/react/docs/component-api.html)
for in-depth specs.

### Core concepts

Reserved props when working with Cosmos: `component`, `componentLookup` and
`state`.

#### Component lookup

In order to make component definitions serializable, Cosmos doesn't work with
classes directly. The `component` prop holds the name of the component, while
the `componentLookup` prop is used for passing a mapping function that returns
corresponding component classes.

Working with the component lookup also results in cleaner component files,
especially when using CommonJS modules with relative paths.

First, we need a component namespace.

```js
var components = {};

// The component classes can be drawn from any global namespace or
// require() mechanism
var componentLookup = function(name) {
  return components[name];
};
```

Then, we can register components into that namespace.

```js
components.Boy = React.createClass({
  mixins: [Cosmos.mixins.PersistState],

  getInitialState: function() {
    return {
      mood: this.props.initialMood
    };
  },

  render: function() {
    return <span>a {this.state.mood} {this.props.eyes}-eyed boy</span>;
  }
});
```

Once that is in place, we are able to render our components.

```js
var props = {
  component: 'Boy',
  componentLookup: componentLookup,
  eyes: 'blue',
  initialMood: 'happy'
};

var boy = Cosmos.render(props, document.body);
```

> "a happy blue-eyed boy"

#### Component snapshot

The props and state of a component can be joined into a unified snapshot. The
`state` prop holds the state of the component.

```js
// Why do people sleep at night?
boy.setState({mood: 'curious'});

var boySnapshot = boy.generateSnapshot();
```

This is what `boySnapshot` will look like:

```js
{
  component: 'my-component',
  componentLookup: [function Function]
  eyes: 'blue'
  state: {
    mood: 'curious'
  }
}
```

Serializing the snapshot is as easy as excluding the `componentLookup` key.

#### State injection

Serializing the state of component is no fun if we can't load it back later.

```js
// The clone will be created in the identical state of the original component
var boyClone = Cosmos.render(boySnapshot);
```



### Mixins

Core mixins are placed under the `Cosmos.mixins` namespace. Read more in the
[Mixins wiki page.](https://github.com/skidding/cosmos/wiki/Mixins)

## Problem

Most web frameworks start out clean and friendly, but at some point after you
go on to build a real-life application on them they stop cooperating and start
turning against you. Finding an honorable route for solving a problem is now a
luxury, workarounds are the norm.

This can happen over and over. Slick at first, unmaintainable in 2 years. But
why is that, why is complexity proportional to the number of features added?

Two reasons:

1. **Interdependence.** Tie a number of units together, rely on one to change
the state of another and you successfully gave birth to
an unpredictable ecosystem
{'fraction_non_alphanumeric': 0.09664183133570889, 'fraction_numerical': 0.001079796998164345, 'mean_word_length': 4.356853672643147, 'pattern_counts': {'":': 0, '<': 21, '<?xml version=': 0, '>': 22, 'https://': 8, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7068827', 'n_tokens_mistral': 2661, 'n_tokens_neox': 2552, 'n_words': 1150}