Каковы общие решения для создания чистого пространства в SPA?

Ответ 1

Если вы повторяете один и тот же код HTML снова и снова с разными идентификаторами, вы делаете что-то неправильно.

В настоящее время существует много способов создания повторно используемых HTML-компонентов, которым не нужны идентификаторы.

Я считаю неправильным:

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

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

Цель состоит в том, чтобы создать структуру с теми компонентами, которые разработчик может использовать для создания представления без необходимости писать какой-либо HTML-код.

Моя точка зрения: HTML-код должен быть написан один раз и только один раз в больших проектах. Очевидно, тот факт, что он написал один раз, не означает, что он может отображаться только в одном месте, он может быть где угодно в приложении.

Мое предложение:

привязка данных к спасению!

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

Ответ 2

Старайтесь избегать использования идентификатора, за исключением случаев, когда это абсолютно необходимо. При ссылках на фрагменты HTML из CSS или JS придерживайтесь классов вместо идентификаторов. Ваши CSS и JS не должны волновать (разделение проблем) о точной структуре DOM или о том, сколько элементов "foo" находятся на странице... они просто хотят стилизовать или действовать на все элементы "foo" какие классы отлично подходят для.

Вы не можете полностью избежать ID, хотя... например, для маркировки вашего HTML для поддержки доступности потребуется использование идентификаторов... но эти идентификаторы и ссылки на них будут ограничены одним и тем же файлом HTML (или SPA), поэтому продолжайте и делайте их многословными/длинными, чтобы избежать конфликтов, если вы чувствуете, что конфликт возможен с любым из них.

Конечно, это не полностью решает вашу проблему. Сосредоточив внимание на классах, вы избегаете возможности генерировать недействительный HTML и все взорвать, но у вас по-прежнему есть проблема совместной работы, заключающаяся в том, что люди не неожиданно прикручивают друг друга, используя одни и те же имена классов. Во многих случаях вы действительно хотите, чтобы одни и те же классы использовались на разных страницах. В тех случаях, когда вы хотите убедиться, что конфликтов нет (например, с использованием общих стилей или стилей типографии на сайте), вы можете обернуть каждый шаблон HTML чем-то вроде <div class='name-of-this-template'>...</div>, а затем в селекторах CSS/JS, область селектор должен соответствовать только этому шаблону: .name-of-this-template .a-class-used-within-the-template.

Ответ 3

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

Команды должны собираться вместе с установленными интервалами для обсуждения сквозных проблем (например, стратегий именования для идентификаторов). Например, если вы используете методологию быстрой разработки Scrum, команды будут периодически встречаться на собрании "Scrum of Scrums", чтобы обсудить такую ​​проблему.

Благодаря разговору команды смогут согласовать соглашение об именах (и документировать согласованную конвенцию для дальнейшего использования), которая наилучшим образом подходит для компонентов, разрабатываемых в то время (и когда я говорю лучше всего в то время, я имею в виду простейший и самый простой для чтения, избегая любых именованных столкновений). Следовательно, ваше предложение "предварительно организовать" идентификатор во время параллельной работы не так смешно, как вы думаете!

Ответ 4

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

Позвольте мне более подробно остановиться.

• Мы используем Backbone.Marionette с шаблоном Handlebars. Для каждого шаблона у нас есть собственный класс вида (мы расширили Backbone.Marionette с большим количеством функций, когда мы продолжали), связанные с каждым шаблоном. Этот класс View имеет элементы ID и UI. Элементы пользовательского интерфейса компилируются в шаблоне, поэтому нам не нужно менять HTML-код, если мы не изменим имя элемента UI в самом классе представления. Поэтому мы можем изменить наш идентификатор элемента пользовательского интерфейса, но мы хотим и ничего не будем влиять (почти).

• Поскольку мы используем представления для каждого виджета, вы можете быть уверены, что их идентификатор или имя или, тем не менее, вы хотите назвать его, уникальны. Мы используем это как основу для нашего идентификатора в наших элементах пользовательского интерфейса. Это позволяет повторно использовать Widget.

• _.uniqueId() из библиотеки Underscore также используется много для CollectionViews.

Надеюсь, я помог, ура!

Ответ 5

Если ваш код (проблема) действительно большой, и вы не можете его реорганизовать, вы можете попробовать проверить свой css/html для поиска повтора id перед каждой фиксацией. Но это возможный ответ для очень плохих ситуаций.

Хорошее решение - использование таких инструментов, как bem (http://bem.info/)

Ответ 6

Дайте каждому разработчику (или модулю) или уникальный идентификатор id.

Например, если разработчик X разрабатывает модуль Y, его префикс должен быть одним из x_, y_ или xy_.
Предполагая, что x_ выбрано, созданные им идентификаторы будут выглядеть как x_foo, x_bar, x_thing и т.д.

Преимущества:

• Удерживает встречные идентификаторы (очевидно).

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

• Написание x_something достаточно раздражает, чтобы избежать чрезмерного отклонения от использования идентификатора.
  В то же время, это не так раздражает, что никто не будет их использовать.

Недостатки:

• Это сделает хотя бы некоторых разработчиков недовольными. (Некоторые из них менее гибкие, чем другие).
  Возможное средство - попросить их изменить идентификаторы на форму x_,
  только к концу развития, непосредственно перед интеграцией.
  До тех пор они могут использовать имена идентификаторов без префикса.

• Некоторые модули зависят от других модулей. Перед интеграцией,
  соответствующие имена идентификаторов должны использоваться совместно и правильно использоваться.
  Хотя это может занять некоторое дополнительное время, он (надеюсь) будет стоить того.

Ответ 7

Я бы предпочел видеть, что идентификаторы используются только для указания модулей, виджетов, основных разделов и т.д. Это приведет к меньшему количеству идентификаторов в целом и большей части вашего наименования, которое будет создано вашей бизнес-логикой. Вы также структурируете свои классы и теги с помощью своего рода локализованной иерархии типа #specialWidget h3 {} #specialWidget p {}, и вы просто выбираете своих обработчиков типа - $('#specialWidget .some-btn').click() и никогда не любите $('#someBtn').click(), потому что это просто беспорядочно и слишком специфично.

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