Сборка фронтенда - часть 2. Тестовое приложение Backbone + Require.js

В предыдущей статье мы договорились разобраться, как собирать фронтенд с помощью gulp. Но предварительно нужно сделать тестовое приложение для того, чтобы было что собирать. В качестве примера сделаем простенькую страничку на Backbone. Управлять модулями будем с помощью require.js. Работать с dom поможет добрая jQuery, а с данными - lodash. Подгружать html-шаблоны мы сможем с помощью requirejs-text.

Так как приложение тестовое, я не буду уделять внимание функциональности - все предельно просто. Обычная страничка с парой текстов и картинкой. Мы создадим одну модель, представление view к ней, загрузим html-шаблон и отрендерим все это добро. Предполагаю, что Вы уже знакомы с Backbone и Require.js, поэтому подробно каждую строчку расписывать не буду. Код очень простой, но все-таки без знания основ этих библиотек не все будет очевидно.

Если Вы не знакомы с Backbone, но интересуетесь созданием Single Page Application в целом и этой замечательной библиотекой в частности, оставляйте комментарии в статье, что-нибудь придумаем :-)

А теперь к делу.

Каркас приложения

В предыдущей части статьи мы уже видели скриншот со структурой проекта. Но это была итоговая структура, уже после настройки gulp. Сейчас когда мы только напишем тестовое приложение, все выглядит немного проще:

Внимание! Для запуска тестового приложения из этой Вам нужно настроить у себя веб-сервер. Просто из папки приложение не запустится. В третьем уроке, когда мы разберем, как это сделать с помощью gulp, все будет работать и так, но пока придется запустить веб-сервер самим или загрузить содержимое папки src на какой-нибудь тестовый домен.

Напоминаю, как будет выглядеть наша итоговая страница. Достаточно сурово, но меж тем мы затронем важные моменты касаемо работы Backbone в связке с Require.js.

Для начала создадим папку img и поместим в нее картинку backbone.js. Все исходники будут в конце третьей статьи. Дальше заведем папку lib, где будут лежать нужные библиотеки.

• 1. jquery - 1.3.3
• 2. lodash - 2.2.4
• 3. backbone - 4.13.1
• 4. require - 2.2.0
• 5. text - 2.0.15

index.html в корне папки будет выглядеть так.
Секция head

Секция body

Конфигурация require.js

Теперь настроим главный файл конфигурации require.js. Сначала привожу код полностью. Файл js/main.js

    'use strict';
    
    // Пути приложения
    var path = {
        base: './js/',
        lib: '../lib/',
        tpl: '../tpl/'
    };
    
    // Конфиг для require.js
    require.config({
        baseUrl: path.base,
        shim: {
            lodash: {
                exports: '_'
            },
            backbone: {
                deps: [
                    'lodash',
                    'jquery'
                ],
                exports: 'Backbone'
            }
        },
        paths: {
            jquery: path.lib + 'jquery',
            lodash: path.lib + 'lodash',
            backbone: path.lib + 'backbone',
            text: path.lib + 'text',
            tpl: path.tpl
        },
        map: {
            '*': {
                'underscore': 'lodash'
            }
        }
    });
    
    // Старт приложения
    require([
        'views/app'
    ], function (
        AppView
    ) {
        new AppView().render();
    });

Сначала для удобства заведем переменную-объект path, в которой укажем пути к папке js со всеми модулями приложения, lib и tpl соответственно, библиотеки и шаблоны для requirejs-text. В require.config указываем базовый url и стандартная для настроек backbone секция shim.

Пути paths кто-то прописывает, кто-то нет, но я предпочитаю настроить их один раз в главном конфиге, чем указывать потом в каждом модуле, думая об относительных путях к файлам-зависимостям.

Секция map тоже наверняка знакома тем, кто пишет на backbone не с помощью underscore, а предпочитает lodash.

И сам старт приложения включает единственную зависимость - представление view/app, пока еще не написанную. Мы создаем новое view и рендерим его. Как это сделать, увидим чуть позже, а пока создадим модель нашего приложения.

Создаем модель приложения

Модели называют сердцем backbone-приложений, и, пожалуй, не зря. Ведь именно они хранят самое важное и интересное с точки зрения программиста - данные. В качестве данных мы иметь в виду заголовок h2 страницы и некое имя пользователя. Впрочем, посмотрим на код. Файл models/app.js

    'use strict';
    
    define(['backbone'], function(Backbone) {
        var AppModel = Backbone.Model.extend({
            defaults: {
                title: 'Webdevkin • Backbone.js + RequireJS',
                username: 'Webdevkin'
            }
        });
    
        // singleton
        var instance;
        return function() {
            if (!instance) {
                instance = new AppModel();
            }
            return instance
        };
    });

Тоже ничего особенного. Дефолтные значения, никакой логики и синглтон, чтобы подчеркнуть, что эта модель должна существовать в единственном экземпляре.

Переходим к представлению.

Представление view и html-шаблон

Содержимое файла views/app.js

    'use strict';
    
    define([
        'lodash',
        'backbone',
        '../models/app',
        'text!tpl/app.html'
    ], function(
        _,
        Backbone,
        AppModel,
        appTpl
    ) {
        var AppView = Backbone.View.extend({
            el: '#app',
            template: _.template(appTpl),
            model: new AppModel,
    
            render: function() {
                this.$el.html(this.template(this.model.toJSON()));
            }
        });
    
        // singleton
        var instance;
        return function() {
            if (!instance) {
                instance = new AppView();
            }
            return instance
        };
    });

Здесь зависимостей в секции define уже больше. В качестве элемента el мы используем #app, шаблон template получаем из внешнего файла tpl/app.html (вскоре напишем). Обязательно указываем модель, попутно создав ее экземпляр. И функция render просто подставит html-строку в el, получив ее из шаблона с данными модели. Синглтон знаком по предыдущему коду.

Не забудем про файл шаблона tpl/app.html.

    

        
<%- title %>
        
Hello, <%- username %>!
        
Пишем простое приложение на Backbone.js
        
    

Если Вы читали мои предыдущие статьи из серии интернет-магазин на фронте, то рендер html-кода из шаблонов покажется Вам очень знакомым. Отличие только в том, что в тех статьях мы работали с underscore и хранили шаблоны прямо в основном html-коде страницы. А теперь мы заменили библиотеку на более продвинутую lodash и как трушные программисты поместили шаблон в отдельный файл.

Стили sass

Последнее, что нам осталось сделать, это написать стили с помощью sass. В папке styles создадим папку modules с файлами _common.scss и _page.scss. Вот их содержимое.

    // _common.scss
    body {
      position: relative;
      color: #333;
      font-family: Helvetica, Arial, sans-serif;
      font-size: 16px;
    }
    
    .wrapper {
      position: relative;
      max-width: 1000px;
      margin: 0 auto;
    }
    
    // _page.scss
    h2 {
      font-size: 20px;
    }
    
    p {
      color: steelblue;
      padding: 20px 0;
    }

А в папке styles создадим общий файл main.scss, который собирает все стили в кучу

    @import 'modules/common';
    @import 'modules/page';

Вы уже можете запустить наше приложение. Если все сделано правильно, веб-сервер настроен, то увидите отрендеренную страничку. Не обращайте внимания, что только что написанные стили не подключились, браузер не нашел файл styles/main.css. Можно создать его вручную, склеив содержимое _common.scss и _page.scss, но предлагаю потерпеть до следующей статьи и возложить это рутинное дело на gulp. В конце концов инструменты сборки для того и нужны, чтобы выполнять за нас подобную работу.

Итоги

Итак, мы написали простое тестовое приложение на Backbone в связке с Require.js. По коду мы пробежались только поверхностно, так как задача наша была не в разборе возможностей библиотеки, а в подготовке приложения, в котором есть много интересных задач для сборки фронтенда.

Если Вы их не увидели, то ничего страшного, в третьей и заключительной части статьи мы преобразуем наше приложение и посмотрим, как много мелких и рутинных задач может сделать за нас gulp даже в таком простом приложении. И что важнее, что приведенная структура позволяет нам расширять функционал сколь угодно, всего один раз настроив сборку фронтенда. Подробности в следующей статье

Все пожелания и вопросы оставляйте в комментариях!