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

Эта статья является продолжением серии, посвященной быстрым и простым решениям общих требований приложений.

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

Императивный код сложен

Во-первых, чем отличается императивный код от декларативного? Прочитав несколько статей по этой теме (одну, которую я нашел особенно полезной), я все еще чувствовал, что знаю, что это такое, но не могу ее сформулировать.

Я знаю, что в следующем примере создание функции myMap обязательно, а использование функции JavaScript map было декларативным.

var myArray = [0, 1, 2];
var myFunction = function(o) {
  return o * 2;
};
// IMPERATIVE
var myMap = function(oldArray, transform) {
  var newArray = [];
  for (var i = 0; i < oldArray.length; i += 1) {
    newArray.push(transform(oldArray[i]));
  } 
  return newArray;
};
// END IMPERATIVE
var mapped = myArray.map(myFunction); // DECLARATIVE
console.log(mapped);
mapped = myMap(myArray, myFunction);
console.log(mapped);

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

Основное преимущество декларативного кода в том, что его меньше. Обратной стороной декларативного кода является его меньшая гибкость.

Выбрать правильный баланс еще сложнее

Я знаю некоторых разработчиков, которые решат большинство проблем с программированием, найдя для этого библиотеку. У этого подхода есть несколько проблем.

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

Я считаю, что у меня есть лучший подход. Столкнувшись с проблемой программирования, я делаю следующее:

  1. Посмотрите, решит ли проблему уже используемая мной библиотека; если так, то я закончил.
  2. Быстро выясните, что мне нужно, чтобы самому разработать решение.
  3. Поищите библиотеку, решающую проблему.
  4. Оцените использование библиотеки и ее создание самим.

Некоторые факторы, которые я учитываю:

  • Время, сэкономленное за счет использования библиотеки.
  • Раздутие, которое библиотека привносит в приложение.
  • Популярность библиотеки.
  • Вводит ли библиотека неприемлемые ограничения (об этом трудно узнать, пока вы не столкнетесь с ними).

Аргумент в пользу интерфейсной платформы

Глядя на пример создания из прошлой статьи, мы обязательно обработали добавление папок в список.

create.html

...
foldersRef.on('child_added', function(data) {
  var folder = data.val();
  var folderEl = document.createElement('li');
  folderEl.appendChild(document.createTextNode(folder.name));
  foldersEl.appendChild(folderEl);
});
...

Чтобы обрабатывать обновления и удаления, мне пришлось бы написать более императивный код, чтобы реагировать на события child_changed и child_removed. Было бы полезно использовать библиотеку, которая, учитывая структуру данных, могла бы управлять ее отображением по мере ее изменения. Обычно это называют шаблонами.

Еще одна проблема, с которой я столкнулся, заключалась в том, что я хотел полностью изменить экран, удалить список папок и отобразить новую форму при обновлении папки. Если бы я решил просто скрывать / отображать элементы DOM при переходе между экранами, я понял, что дерево DOM станет довольно раздутым. Если бы я решил добавить / удалить элементы DOM, мне пришлось бы иметь дело с добавлением и удалением прослушивателей событий DOM. Опять же, была бы полезна библиотека для управления заменой экранов. Обычно это называется маршрутизацией.

Хорошая новость в том, что существует ряд отличных библиотек, интерфейсных фреймворков, которые решают эти и связанные с ними проблемы. Активно используя как Backbone.js, так и Angular (версия 1.x), я переключился на React и до сих пор не пожалел о своем решение. Таким образом, оставшаяся часть этой серии будет посвящена созданию с помощью React.

Дальнейшие действия

В следующей статье серии Обучение на хакатоне: Часть 5 мы начнем реализацию полного CRUD-приложения с использованием интерфейсной среды React.