Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Web Development
Code

Створення односторінкового додатка для складання списку завдань за допомогою Backbone.js

by
Difficulty:BeginnerLength:LongLanguages:

Ukrainian (українська мова) translation by AlexBioJS (you can also view the original English article)

Backbone.js – JavaScript-фреймворк для створення гнучких веб-застосувань. Він надає Моделі, Колекції, Події, Маршрутизатор та декілька інших чудових можливостей. У цьому посібнику ми розробимо простий додаток для складання списку завдань з можливостями їх додання, редагування та видалення. Ми також додамо можливість відмітити, що завдання виконано, та помістити його до архіву. Для того щоб довжина цього поста залишалася прийнятною, ми не будемо додавати ніякої взаємодії з базою даних. Всі дані будуть зберігатися на стороні клієнта.

Попередні підготування

Нижче наведено файлову структуру, яку будемо використовувати:

Призначення пари файлів очевидно, наприклад /css/styles.css та /index.html. Вони містять стильові правила CSS та HTML-размітка. У контексті Backbone.js модель є місцем для зберігання наших даних. Так що наші завдання списку просто будуть моделями. І оскільки у нас буде більше одного завдання, ми організуємо їх у вигляді колекції. Бізнес-логіка (* програмний код, що реалізує функціональність застосування. Тут і надалі примітка перекладача) розподіляється між представленнями та головним файлом застосування, App.js. Із залежностей для Backbone.js обов'язкова тільки Underscore.js. Цей фреймворк також дуже добре сполучається з jQuery, так що обидві ці бібліотеки додаються до папки vendor (* постачальник, вендор). Все, що нам тепер потрібно, – просто написати трохи коду HTML-розмітки, і ми готові до створення застосування.

Як ви бачите, ми підключаємо всі зовнішні файли JavaScript ближче до кінця документа, оскільки згідно з усталеною практикою це потрібно виконувати у кінці тегу body. Також ми підготовлюємо код для поетапного завантаження застосування. У документі є контейнер для контенту, меню та заголовка. Головне навігаційне меню є статичним елементом, і ми не будемо його змінювати. Ми замінимо контент заголовка та елемента div, розташованого нижче нього.

Планування додатка

Завжди добре, якщо ви маєте план перед початком роботи з будь-чим. У Backbone.js нема дуже строгих архітектурних принципів, яких нам варто дотримуватися. Це є однією з переваг даного фреймворка. Так що, перед тим як взятися за реалізацію бізнес-логіки, давайте розглянемо основні принципи.

Визначення простору імен

(* набір правил іменування, що регулює видимість об'єктів у програмі або хост-комп'ютерів у комп'ютерній мережі. Простір імен може бути плоским (flat namespace) та ієрархічним (hierarchical namespace). Передбачено, що всі імена у просторі імен мають бути унікальними). Згідно з усталеною практикою ваш код потрібно розташовувати в його власній області видимості (* області тексту програми, де можна використати заданий ідентифікатор (ім'я змінної, іменована константи, назва функції тощо). Область видимості можна змінити, перевизначивши ідентифікатор, але краще просто не використовувати в різних блоках програми однакові імена). Реєстрація глобальних змінних або функцій – погана ідея. Ми створимо одну модель, одну колекцію, маршрутизатор та декілька представлень Backbone.js. Всі ці елементи повинні знаходитися у власній області видимості. В App.js буде міститися клас (* імітація класу), у якому роташовується весь код.

Вище наведено типову реалізацію шаблону проектування (* у програмування – узагаьлнений опис способу вирішення певного класу задач) «Відкритий модуль". У змінній api міститься об'єкт, повертаємий функцією, який надає доступ до публічних методів класу. Властивості views, models и collections будуть виступати в якості вмістищ класів, повертаємих Backbone.js. У content буде міститися об'єкт jQuery для головного контейнера користувальницького інтерфейсу. Тут ми маємо два допоміжних методи. За допомогою першого оновлюється вищезгаданий контейнер. За допомогою другого задається текст заголовка сторінки. Потім ми визначаємо модуль під назвою ViewsFactory. У ньому будуть створюватися представлення, і в кінці ми створили маршрутизатор.

Ви можете поцікавитися, навіщо нам потрібна фабрика (* в ООП – клас (class), використовуваний для створення екземплярів (instance) інших класів. Фабрика потрібна, щоб ізолювати створення об'єктів певного класу. Така локалізація дозволяє легше додавати до об'єктів нові функції (методи)) для представлень? Що ж, для роботи з Backbone.js є деякі поширені шаблони. Один із них стосується створення та використання представлень.

Добре, якщо ви ініціалізували представлення тільки один раз та залишили їх у такому стані. Одразу після зміни даних ми звичайно викликаємо методи представлення та оновлюємо контент його об'єкта el. Іншим дуже поширеним підходом є повторне створення всього представлення або заміна всього елемента DOM. Проте це не зовсім вдалий видір з точки зору продуктивності. Тому ми звичайно використовуємо допоміжний клас, за допомогою якого створюється та повертається за потреби один екземпляр преставлення.

Визначення копонентів

Ми маємо простір імен, так що тепер ми можемо взятися за створення компонентів. Нижче показано, як виглядає код для головного меню:

Ми створили властивість під назвою menu, у якій зберігається клас для навігаційного меню. Пізніше ми можемо додати у модулі фабрики метод, за допомогою якого створюється його екземпляр.

Вище показано, як ми створимо всі представлення, і завдяки цьому підходу буде гарантовано, що ми отримуємо тільки одне представлення того самого типу. У більшості віпадків цей підхід працює чудово.

Потік даних

У якості точки входу додатка виступає App.js та розташований у його коді метод init. Нижче показано, що ми викличемо в обробнику події onload для об'єкта window:

Після цього керування передається вказаному маршрутизатору. За допомогою нього на основі URL-адреси вибирається, який обробник запускати. У Backbone.js нема типової архітектури Модель-Представлення-Контролер (* MVC – Model-View-Controller). Контролер відсутній, і більша частина логіки переходить до представлень. Так що ми підв'язуємо моделі безпосередньо до методів представлень, і користувальницький інтерфейс після зміни даних негайно оновлюється.

Керування даними

Найважливіша частина нашого невеликого проекту – дані. Нам потрібно керувати нашими завданнями, так що давайте почнемо з них. Нижче наводиться визначення нашої моделі.

Всього-на-всього три поля. У перше поміщається текст завдання, а за допомогою решти, що є прапорцями, відмічається статус запису.

Всі об'єкти у розглядуваному тут фреймворку є власне розподільниками подій. І оскільки модель змінюється за допомогою сеттерів, фреймворк знає, коли оновлюються дані, і може сповістити решту частин системи про це. Тільки-но ви підключили щось для цих сповіщень, ваш додаток відреагує на зміни у моделі. Це дійсно потужна можливість Backbone.js.

Як я згадав на початку, у нас буде безліч записів і ми організуємо їх у вигляді колекції під назвою ToDos.

Код колекції починається з методу initialize. У нашому випадку ми додали декілька завдань за налаштуванням. Звісно ж, у реальному світі розробки інформація буде надходити з бази даних або ще звідкілясь. Але щоб не розсіювати вашу увагу, ми зробимо це вручну. Інший характерний для колекції момент – завдання значення властивості model. За допомогою нього класу повідомляється інформація про тип зберігаємих даних. Завдяки решті методів реалізується логіка, що має відношення до можливостей нашого застосування. За допомогою функцій up та down змінюється порядок розташування записів. Задля простоти ми будемо ідентифікувати кожне завдання тільки за допомогою масиву колекції. Це означає, що якщо нам потрібно отримати один конкретний запис, то ми повинні вказати його індекс. Таким чином, для зміни порядку розташування записів нам потрібно лише переставити елементи у масиві. Як ви можете здогадатися з коду вище, this.models – той масив, про який йде мова. За допомогою archive та changeStatus задаються значення властивостей переданого елемента. Ми додаємо ці методи тут, оскільки представлення будуть мати доступ до колекції ToDos, а не безпосередньо до завдань.

Також нам не потрібно створювати будь-які моделі класу app.models.ToDo, проте нам дійсно потрібно створити зразок колекції app.collections.ToDos.

Відображення нашого представлення (Головного навігаційного меню)

Перше, що нам потрібно відобразити, – головне навігаційне меню додатка.

У файлі вище тільки дев'ять рядків коду, проте там відбувається багато крутих речей. По-перше, визначення шаблону. Пам'ятаєте, що ми додали Underscore.js до застосування? Ми будемо використовувати її шаблонізатор (* ПЗ для комбінування шаблонів з моделлю даних для отримання кінцевих документів), оскільки він добре працює та ним легко користуватися.

У результаті ви отримуєте функцію, що приймає об'єкт, який містить вашу інформацію у вигляді пар ключ-значення, і templateString – це HTML-розмітка. Добре, отже у вищезазначену функцію передається рядок з HTML-розміткою, але навіщо там використовується $("#tpl-menu").html() ? При розробленні невеликих односторінкових додатків ми звичайно додаємо шаблони безпосередньо до документу наступним чином:

І оскільки це тег script, то шаблон не показується користувачеві. З іншого боку, це звичайний вузол DOM, так що ми могли би отримати його контент за допомогою jQuery. Таким чином, за допомогою невеликого фрагменту коду вище просто отримується контент того тегу script.

Метод render дуже важливий у Backbone.js. Це функція, за допомогою якої відображуються дані. Звичайно ви прив'язуєте генеровані моделлю події безпосередньо до цього методу. Проте у випадку з головним меню нам цього не потрібно.

this.$el – об'єкт, створений фреймворком, і кожне представлення має його за налаштуванням (перед el йде $, оскільки ми підключили jQuery). І за налаштуванням його значенням є пустий <div></div>. Звісно ж, ви можете змінити його за допомогою властивості tagName. Проте тут важливіше те, що ми не присвоюємо значення тому об'єкту безпосередньо. Ми його не змінюємо, ми змінюємо тільки його контент. Між рядком вище та наступним рядком є велика різниця:

Смисл полягає у тому, що якщо ви хочете побачити зміни у браузері, то ви повинні для початку викликати метод render, щоб додати представлення до DOM. Інакше буде додано тільки пустий елемент div. Також може бути інший сценарій, коли ви маєте укладені представлення. А оскільки ви змінюєте безпосередньо властивість, то батьківський компонент не оновлюється. Також може порушуватися прив'язка до подій, і вам потрібно буде знову підключати обробники. Таким чином, вам дійсно потрібно змінювати тільки контент this.$el, а не значення властивості.

Тепер представлення готове, і нам потрібно його ініціалізувати. Давайте додамо його до нашого модулю фабрики:

Нарешті, просто викличте метод menu в області для самоналаштування додатка:

Зверніть увагу на те, що хоча ми й створюємо новий зразок класу навігаційного меню, ми передаємо вже існуючий елемент DOM $("#menu"). Тому у властивості this.$el всередині представлення міститься посилання власне на $("#menu").

Додання маршрутів

У Backbone.js є підтримка операцій додавання станів до стека. Іншими словами, ви можете маніпулювати поточною URL-адресою браузера та переходити між сторінками. Проте ми скористаємося старими добрими URL-адресами з геш-префіксом (* геш url – все, що йде після символу #), наприклад /#edit/3.

Вище наведено наш маршрутизатор. У геші (* колекція пар ключ-значення, причому ключом є рядок) є п'ять маршрутів. Ключ – те, що ви будете набирати в адресному рядку браузера, а значення – функція, яка буде викликатися. Зверніть увагу на те, що у складі двох маршрутів є :index. Це відповідає синтаксису, якого ви повинні дотримуватися, якщо хочете реалізувати підтримку динамічних URL-адрес. У нашому випадку, якщо ви набираєте #edit/3, то при виклику editToDo в якості значення параметра index буде передано 3. В останній парі міститься пустий рядок, і це означає, що вона використовується для реалізації переходу на домашню сторінку нашого застосування.

Відображення всього списку завдань

На даний момент ми створили головне представлення для нашого проекту. Дані будуть передано до нього з колекції та виведено на екран. Ми могли би використовувати те саме представлення для двох цілей – відображення всіх активних завдань та тих, що поміщено до архіву.

Перед тим як продовжити реалізацію представлення для списку, давайте подивимося, як воно власне ініціалізується.

Зверніть увагу на те, що ми передаємо колекцію. Це важливо, оскільки пізніше ми скористуємося this.model для отримання збережених даних. Фабрика повертає наше представлення для списку, проте саме за допомогою маршрутизатора воно повинно бути додано на сторінку.

Поки що метод list у маршрутизаторі викликається без будь-яких аргументів. Так що представлення знаходиться не в режимі archive; за допомогою нього будуть відображуватися тільки поточні завдання.

Властивість mode буде використано при рендерінгу. Якщо його значенням є "archive", то буде відображено тільки записи, що знаходяться в архіві. events – об'єкт, який ми заповнимо дуже скоро. Це місце, де ми назначаємо подіям DOM відповідні обробники. Решта методів використовується для реагування на дії з боку користувача та безпосередньо для реалізації потрібних можливостей додатка. Наприклад, за допомогою priorityUp та priorityDown змінюється порядок розташування завдань. Завдяки archive елемент переміщається до архіву. За допомогою changeStatus відмічається, що завдання виконано.

У методі initialize відбувається дещо цікаве. Раніше ми згадали, що звичайно ви будете підв'язувати до подій, що виникають при змінах у моделі (колекції у нашому випадку), метод render представлення. Ви можете написати this.model.bind('change', this.render). Проте дуже скоро ви помітите, що ключове слово this у методі render не буде вказувати на саме представлення. Так відбувається через зміну області видимості. У якості обхідного шляху ми створюємо обробник з вже заданою областю видимості. Саме для цього і служить функція bind Underscore.

А нижче наводиться реалізація методу render.

Ми перебираємо всі моделі колекції та генеруємо HTML-рядок, який пізніше вставляється до DOM-елемента представлення. Виконується декілька перевірок для визначення того, чи належать завдання до тих, що знаходяться в архіві, або до поточних. За допомогою прапорця відмічається, що завдання виконано. Так що, для того щоб це вказати, нам потрібно передати атрибут checked=="checked" тому елементу. Ви, ймовірно, помітили, що ми використовуємо this.delegateEvents(). У нашому випадку це потрібно, оскільки ми відв'язуємо представлення від DOM та прив'язуємо його до нього. Так, ми не змінюємо головний елемент, проте обробники подій видаляються. Тому нам потрібно вказати Backbone.js, що їх варто знову підключити. Використаний у коді вище шаблон виглядає наступним чином:

Зверніть увагу, що вказано клас CSS під назвою done-yes, за допомогою якого завдання відображується із зеленим фоном. Окрім цього є безліч посилань, які ми будемо використовувати для реалізації потрібних функціональних можливостей. Вони всі мають власні атрибути HTML5 Data. Головний вузол елемента, li, має data-index. За допомогою значення цього атрибуту вказується індекс завдання у колекції. Зверніть увагу на те, що спеціальні вирази, обгорнуті у <%= ... %>, передаються до функції template. Це дані, передавані до шаблону.

Прийшов час додати деякі події для представлення.

У Backbone.js для визначення подій використовується просто геш. Спочатку ви вказуєте ім'я події, а потім – селектор. Значення властивості є власне методами представлення.

Тут ми використовуємо e.target, передаваний до обробника. У ньому знаходиться посилання на елемент DOM, що згенерував подію. Ми отримуємо індекс вибраного завдання та оновлюємо модель у колекції. Після додання цих чотирьох функцій наш клас готовий, і тепер дані відображаються на сторінці.

Як було згадано раніше, ми будемо використовувати те саме представлення і для сторінки Archive.

Вище наведено той самий обробник для маршруту, що й раніше, проте у цей раз йому в якості аргументу передається значення true.

Реалізація можливості додавання та редагування завдань

Беручи за приклад представлення для списку, ми могли би створити інше, за допомогою якого відображується форма для додавання та редагування завдань. Нижче показано, як створюється клас для цього:

Код дуже схожий на той, що бачили раніше. Проте, цього разу нам потрібно дещо виконати після відправлення форми, а саме перенаправити користувача на головну сторінку. Як я сказав раніше, кожний об'єкт, що наслідує характеристики класів Backbone.js, є власне розподільником подій. Є методи на зразок on та trigger, якими ви можете скористатися.

Перед тим як ми продовжимо розбиратися з представленням, давайте поглянемо на HTML-шаблон:

У нас є textarea та button. До шаблону повинен передаватися аргумент title, значенням якого повинен бути пустий рядок, якщо ми додаємо нове завдання.

Код представлення містить всього-на-всього 40 рядків, проте він виконую свою задачу. Є лише один розробник події, що виникає при натисненні кнопки save. Метод render веде себе по-різному в залежності від значення переданого аргументу index. Наприклад, якщо ми редагуємо запис, то передаємо індекс та отримуємо конкретну модель. Якщо ні, то форма пуста та буде створено нове завдання. У коді вище є декілька цікавих моментів. По-перше, у render ми скористалися методом .focus() для переміщення фокуса до форми одразу після відображення представлення. Знов-таки, потрібно викликати функцію delegateEvents, оскільки форма могла би бути відв'язана та прив'язана знову. Метод save починається з e.preventDefault(). У результаті поведінка кнопки за налаштуванням відміняється, яке у деяких випадках може полягати у відправленні форми. У кінці, після того як все виконано, ми генеруємо подію saved, за допомогою якої решта частин системи сповіщається про те, що завдання збереглося до колекції.

Нам потрібно реалізувати два методи для маршрутизатора.

Різниця між ними полягає у тому, що ми передаємо index, якщо перехід виконується за маршрутом edit/:index. І, авжеж, заголовок сторінки змінюється відповідним чином.

Реалізація можливості видалення запису з колекції

Для реалізації цієї можливості нам не потрібно представлення. Вас потрібне може бути виконано безпосередньо в обробнику маршрутизатора.

Нам відомий індекс завдання, яке ми хочемо видалити. Є метод remove класу колекції, який приймає об'єкт моделі. У кінці перенаправлюємо користувача на головну сторінку, де відображується оновлений список.

Завершення

Backbone.js надає вам всі можливості, потрібні для створення повнофункціональних одностроінкових застосувань. Ми би могли навіть прив'язати його до RESTful веб-служби (* веб-сервіс, побудований згідно з REST (Representational State Transfer – передача репрезентативного стану)) на стороні сервера, і за допомогою цього фреймворка дані вашого застосування були би синхронізовані з базою даних. Завдяки подійно-керованому підходу розроблення (* спосіб проектування програмних систем, при якому поведінка компонента системи визначається набором можливих зовнішніх подій та реакцій у відповідь копонента на них; спосіб поведінки системи, за якого усі події можна ідентифікувати й кожну з них пов'язати з послідовністю дій, виконуваних під час її виникнення. Події у системі можуть виникати асинхронно) нам стає легше використовувати метод модульного програмування (* один із ранніх методів проектування програм. Усю програму розбивають на модулі, кожний із який виконує одну функцію і містить весь потрібний для цього код і змінні, що дозволяє програмувати й налагоджувати його окремо. Потім модулі поступово збирають разом, поки не буде реалізовано всю систему. Цей підхід дозволив зменшити складність розробки і налагодження великих програм. Принципи модульного програмування стали складовою частиною ООП) та побудувати добру архітектуру. Особисто я використовую Backbone.js для декількох проектів, і він відмінно працює.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.