Мышление вне DOM: концепции и настройка

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

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

Что такое муфта?

Во многих приложениях код взаимодействует с различными внешними API. В веб-приложениях мы взаимодействуем с DOM API, возможно, сетью (через XMLHttpRequest), JSON или XML для обмена данными и многими другими. На концептуальном уровне эти проблемы строго отделены друг от друга.

Если REST API, с которым взаимодействует ваше приложение, вносит несколько структурных изменений, разумно, что вам нужно обновить код, взаимодействующий со службой REST. Это не разумно, что это требует изменений в коде рендеринга пользовательского интерфейса. Тем не менее, очень часто это происходит. И когда это происходит, у вас есть то, что называется «тесная связь».

Слабая связь противоположна жесткой связи. В слабосвязанной системе изменение требований к сети не приводит к изменениям в коде рендеринга. Обновленная таблица стилей CSS и новые правила для имен классов не вызывают изменений в коде сериализации данных. Это означает меньше проблем и кодовую базу, о которой легче рассуждать.

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

Проверка формы

Проверка формы — возможно, самая лучшая лошадь, которую вы когда-либо могли победить с помощью флешки JavaScript. Это один из старейших сценариев использования JavaScript, который решался библиотеками с открытым исходным кодом раз в миллион раз, не говоря уже о введении таких атрибутов HTML5, как required и pattern . Тем не менее, новые библиотеки все еще всплывают, указывая, что:

1. Мы не создаем правильные абстракции, что приводит к постоянной необходимости переписывать.
2. Разработчикам JavaScript действительно нравится изобретать велосипед (и публиковать результат в виде программного обеспечения с открытым исходным кодом).

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

Проверка формы «близка» к DOM во многих отношениях. Мы тестируем набор ожиданий относительно текущего состояния form , а затем сообщаем пользователю, внося изменения в DOM. Однако, если мы сделаем шаг назад, мы можем легко представить некоторые соответствующие варианты использования, которые в меньшей степени включают DOM:

• Отправка отчетов о проверке в систему аналитики, чтобы понять, как улучшить дизайн сайта.
• Проверка данных, полученных по сети
• Проверка данных из файлов, перетаскиваемых в браузер
• Вывод проверочных сообщений с использованием таких библиотек, как React

Даже если DOM активно задействован, существует множество факторов, которые различаются:

• Когда проверка запускается? Когда onsubmit событие onsubmit ? onblur ? onchange ? Программно через код JavaScript?
• Сообщение об ошибке по всей форме или по полю? И то и другое?
• Сведения о разметке отчетов об ошибках могут сильно различаться
• Отчеты об ошибках могут отличаться в зависимости от контекста

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

Как будто этого было недостаточно, учтите тот факт, что многие виды правил проверки зависят от более чем одного поля. Как мы решаем эти ситуации? Ответ можно найти, сначала проанализировав, что нам нужно сделать, а затем решив, как лучше всего это сделать:

• Чтение данных из формы (DOM-ориентированных)
• Проверка данных по набору правил (чистая бизнес-логика)
• Вывод результатов проверки (возможно, DOM-ориентированных)

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

Проверка данных

Ядром любой библиотеки валидации является ее набор функций валидации. Эти функции должны быть применимы к любым данным, а не только к элементам формы. В конце концов, единственное, что отличает принудительное использование поля name в форме от обязательного обеспечения наличия свойства имени объекта, — это то, как мы получаем доступ к значению. Сама логика проверки идентична. По этой причине было бы разумно спроектировать функции валидатора для работы с чистыми данными, а затем предоставить различные механизмы для извлечения значений для прохождения через валидатор отдельно. Это также означает, что наши модульные тесты могут использовать простые объекты JavaScript, что приятно и легко сделать.

 var checkName = required("name", "Please enter your name"); 

 var result = checkName({name: 'Chris'}); 

 // returns {id: "name", msg: "Please enter your name"} checkName({}); 

 describe('required', function () { it('does not allow required fields to be blank', function () { var rule = required('name', 'Name cannot be blank'); assert.equals(rule({}), { id: 'name', msg: 'Name cannot be blank' }); }); }); 

 function required(id, msg) { return function (data) { if (data[id] === null || data[id] === undefined || data[id] === '' ) { return {id: id, msg: msg}; } }; } 

 var rules = [ required("name", "Please enter your name"), required("email", "Please enter your email") ]; var data = {name: "Christian"}; // [{id: "email", messages: ["Please enter your email"]}] var errors = enforceRules(rules, data); 

 describe('required', function () { it('does not allow required fields to be blank', function () { var rules = [required('name', 'Name cannot be blank')]; assert.equals(enforceRules(rules, {}), [ {id: 'name', messages: ['Name cannot be blank']} ]); }); }); 

 function enforceRules(rules, data) { var tmp = {}; function addError(errors, error) { if (!tmp[error.id]) { tmp[error.id] = {id: error.id}; tmp[error.id].messages = []; errors.push(tmp[error.id]); } tmp[error.id].messages.push(error.msg); } return rules.reduce(function (errors, rule) { var error = rule(data); if (error) { addError(errors, error); } return errors; }, []); } 

 function pattern(id, re, msg) { return function (data) { if (data[id] && !re.test(data[id])) { return {id: id, msg: msg}; } }; }