Какова лучшая практика для создания додзё додзё?

Question

Какова лучшая практика для создания додзё додзё?

Чисто декларативный подход (D)
Чисто программный подход (P)
Сочетание двух (D&P)

критерии

Самый простой в обслуживании
Быстрее всего развиваться с
Самый интуитивный
Лучшее представление
Большая функциональность и гибкость

контекст

Я работаю с Dojo чуть меньше месяца, и недавно я начал работать с библиотекой dijit. Один из хорошо разрекламированных аспектов dijits - то, что они могут быть объявлены программно или декларативно. Мне всегда нравится подходить к новому набору инструментов с пониманием лучших практик и некоторой общей идеи о том, какой подход имеет какие преимущества / преимущества для конкретного приложения.

Приведенная ниже информация основана на некотором личном опыте работы с обоими стилями, а также на справочном материале, который мне удалось найти, что не так уж много. Эта ссылка - единственная, которую я нашел в официальной документации Dojo по этому вопросу, и этот пост дает некоторую внешнюю перспективу с основным представлением о том, как код для каждого выглядит для простых сценариев. Обе ссылки предназначены для более старых версий dojo, до того, как AMD была представлена в версии 1.7.

программный

Отделяет Dojo от HTML, который сохраняет семантическую чистоту HTML
Устанавливает обработчики событий и виджеты в одном месте, повышая читабельность
Кажется, чтобы упростить динамическое назначение значений атрибутам (например, создать уникальные идентификаторы с помощью функции)

декларативный

Быстрое развитие - интуитивное, подразумеваемое вложение, виджеты, определенные как обычные элементы HTML
Допустимый HTML5 с использованием атрибутов data-jojo-*
Не сохраняет семантической чистоты HTML
Обработчики событий приходят извне сценариев, создавая некоторую сложность и снижая читабельность
Первоначальный parseOnLoad может замедлить предварительную настройку виджета

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

Обновление:

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

0

javascript dojo dojo-1.9

Источник

user2486302 18 окт '13 в 15:07

1 ответ

Решение

Другие вопросы по тегам javascript dojo dojo-1.9

user1915448 18 окт '13 в 18:14 2013-10-18 18:14 · Accepted Answer · 2013-10-18 18:14

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

Я думаю, что имеет больше смысла отделить уровень представления от уровня бизнес-логики (что-то вроде архитектуры n-уровня). Я имею в виду, какая разница между dijit/form/TextBox и стандарт <input type="text" /> Элемент HTML? Они оба являются частью уровня представления и имеют одну и ту же цель. Единственное отличие состоит в том, что один является пользовательским элементом, а другой - нет.

Но с другой стороны, я рассматриваю обработку и проверку событий как бизнес-логику, поэтому я бы поместил их в JavaScript. Вы также можете объявить свой dojo/store объекты декларативные, это также то, что мне не нравится, потому что это не имеет отношения к моему уровню представления.

Теперь вернемся к рассмотрению ваших пунктов:

Проще всего поддерживать: если бы мне пришлось изменить виджет dijit, я бы, вероятно, посмотрел в HTML (разделение задач; представление <-> бизнес-логика). Это также легче найти. Например, если вы знаете, что виджет dijit находится прямо под заголовком и чуть выше кнопки, то вы точно знаете, где искать в своем HTML-коде. Если бы мы сделали это программно, это могло бы быть где угодно в вашем коде.

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

Наиболее интуитивно понятен: я также обращаюсь к этому в первой части (проще всего поддерживать). Я также думаю, что это очень хорошо, что они также используют несколько стандартных атрибутов HTML, таких как title, value, placeholder... Я не думаю, что это загрязняет вашу HTML-разметку, но также повышает читабельность.

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

<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />

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

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

С другой стороны, это выглядит грязно, когда вы создаете виджет программно (это мнение), поэтому я могу определить это в HTML, где это намного проще.

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

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

Чем больше файлов, тем меньше они обычно и тем легче их читать (тем самым снижается сложность и повышается читаемость). У вас может получиться много файлов, но если вы правильно их назовете (и, возможно, задокументируете), проблем быть не должно.

Но, в конце концов, это мнение, возможно, есть и другие мнения, которые так же хороши или даже лучше, чем мое. Иногда это также зависит от ситуации: если производительность действительно является одним из самых больших требований, то определение всего в JavaScript также может быть лучшим решением. Не похоже, что эти правила где-то высечены в камне.