.js

A Non-Frameworky Framework

Luke Karrys

Luke Karrys - I work for &yet - Ampersand core team member
Yeti, Finding Bigfoot, 1500x
I'm going to talk about
-- What is ampersand
-- Some philosophy behind it
-- Dive into some code to solve a few problems

What is Ampersand?

Backbone-esque

Node style modules

Advanced features

Backbone is very flexible, we derived from that
Broken up into node-style modules
Lacked the power features needed today
Evident by everyone having their own Backbone "flavor"
Ampersand enhanced for today's features you need

No monolithic core

npm installampersand-view ampersand-state ampersand-collection ampersand-subcollection ampersand-router ampersand-model ampersand-view-switcher ampersand-version ampersand-sync ampersand-form-view ...

There is no core.
No single module to install. `ampersand` is just the cli
Ampersand is more just the well defined approach we've created to combining all those modules.
You don't need all of these by any means, but we try to solve the common problems
npm install and... npm install and...

Node Style

Everything is on

Small, focused modules

Semver + quick releases

npm test browserify test/* | tape-run

npm start run-browser test/index.js

Built for the browser

What does node style mean?

npm! keyword link
Inline with the node/unix tiny modules philosophy
Semver: we're careful to only make breaking changes when necessary, but semver gives us the ability to do that and release quickly
CLI and browser test scripts, use with testling, travis
Issue/PR === same day
Combine all this as modules for easy consumption via browserify or webpack

Flexible!??

When you say flexible, I hear footguns. Anyone who has been burned by "flexible" tools

Offset by:

Well defined approachesMaximized simplicity

Flexibility is a double-edged sword
Ask anyone who has built a huge app on Backbone (/me raises hand)
15k lines of backbone code...footguns everywhere
We try to fight for simplicity and well defined appoaches

Composable

└─┬ ampersand-model@4.0.3
  ├── ampersand-state@4.3.14
  ├── ampersand-sync@2.0.4
  └── ampersand-version@1.0.1

└─┬ ampersand-rest-collection@2.0.3
  ├── ampersand-collection@1.3.17
  ├── ampersand-collection-rest-mixin@3.0.0
  └── ampersand-collection-underscore-mixin@1.0.2

└─┬ ampersand-view@7.1.4
  ├── ampersand-collection-view@1.1.2
  ├── ampersand-dom-bindings@3.3.1
  └── ampersand-state@4.3.14 # !!!

└─┬ ampersand-YOUR-MODULE-OR-MIXIN@1.0.0
  ├── react@???
  ├── some-new-crazy-stuff-no-one-has-ever-heard-of@???
  └── ampersand-state@4.3.14

Composable pieces make up the main pieces
Model is state + rest
Rest collection is collection + REST
View + State!
Create your own
I spend time creating ampersand views that could be used across differnt apps with the same business logic

State

var Person = State.extend({
    props: {
        name: 'string'
    },
    session: {
        type: {
            type: 'string',
            default: 'JS'
        }
    },
    derived: {
        title: {
            deps: ['name', 'type'],
            fn: function () {
                return this.type + ': ' + this.name;
            }
        }
    }
});
var person = new Person();
person.on('change:title', console.log.bind(console));
person.name = 'Luke Karrys'; // "JS: Luke Karrys"
person.type = 'Ampersand'; // "Ampersand: Luke Karrys"

Derived properties
Session properties and props to server
Change events for all

Nested State

var Project = State.extend({
    children: {
        assignee: Person
    },
    props: {
        id: 'string',
        name: 'string'
    },
    derived: {
        title: {
            deps: ['assignee.title', 'name'],
            fn: function () {
                return this.name + ' / ' + this.assignee.title;
            }
        }
    }
});
var project = new Project({assignee: {name: 'Luke Karrys'}});
project.on('change:title', console.log.bind(console));
project.name = 'JSLA'; // "JSLA / JS: Luke Karrys"
project.assignee.type = '&.js'; // "JSLA / &.js: Luke Karrys"

Derived from children
State is really powerful for modeling all the relationships in your app

Subcollections

var Projects = Collection.extend({model: Project});
var projects = new Projects(projectsData);

var ampersand = new SubCollection(projects, {
    filter: function (model) {
        return model.assignee.type === 'Ampersand';
    },
    watched: ['assignee.type']
});

console.log(ampersand.length); // 5
ampersand.at(0).assignee.type = 'JS';
console.log(ampersand.length); // 4
ampersand.at(0).assignee.type = 'JS';
console.log(ampersand.length); // 3

Using derived properties from models within a collection to trigger subcollections

Stateful Views

var ProjectView = View.extend({
    template: '<li></li>',
    bindings: {
        'title': 'li'
    },
    derived: {
        title: {
            deps: ['model.id', 'model.title'],
            fn: function () {
                return '(' + this.model.id + ') ' + this.model.title;
            }
        }
    }
});

Item view
Keep view state in the view
Bindings
item view is keeping track of all our model changes

Render Collection

var AppView = View.extend({
    template: '<ul class="ampersand"></ul>',
    render: function () {
        this.renderWithTemplate();
        this.renderCollection(ampersand, ProjectView, '.ampersand');
        return this;
    }
});
new AppView({ el: document.querySelector('.container') }).render();