Поскольку JavaScript-фреймворки, такие как jQuery, делают клиентские веб-приложения богаче и функциональнее, я начал замечать одну проблему ...
Как в мире вы держите это организованным?
- Разместите все свои обработчики в одном месте и напишите функции для всех событий?
- Создать функцию / классы, чтобы обернуть всю вашу функциональность?
- Писать как сумасшедший и просто надеяться, что все получится лучше
- Сдаться и начать новую карьеру?
Я упоминаю jQuery, но это вообще любой код JavaScript. Я обнаружил, что, когда строки за строками начинают накапливаться, становится сложнее управлять файлами сценариев или находить то, что вы ищете. Вполне возможно, что самые большие проблемы, которые я обнаружил, состоят в том, что существует множество способов сделать то же самое, и трудно понять, какой из них является общепринятым в настоящее время.
Есть ли общие рекомендации о том, как сохранить ваши файлы .js такими же красивыми и аккуратными, как и все остальное в вашем приложении? Или это просто вопрос IDE? Есть ли лучший вариант там?
РЕДАКТИРОВАТЬ
Этот вопрос предназначался скорее для организации кода, а не для организации файлов. Было несколько действительно хороших примеров слияния файлов или разделения контента.
Мой вопрос: каков на сегодняшний день общепринятый способ организации вашего кода? Каков ваш способ или даже рекомендуемый способ взаимодействия с элементами страницы и создания повторно используемого кода, который не конфликтует друг с другом?
Некоторые люди перечислили пространства имен, что является хорошей идеей. Каковы другие способы, более конкретно относящиеся к элементам на странице и поддерживающие упорядоченный и аккуратный код?
Ответы:
Было бы намного лучше, если бы в javascript были встроены пространства имен, но я обнаружил, что организация таких вещей, как Дастин Диаз, описанная здесь, мне очень помогает.
Я помещаю разные «пространства имен», а иногда и отдельные классы в отдельные файлы. Обычно я начинаю с одного файла и, когда класс или пространство имен становится достаточно большим, чтобы его оправдать, я разделяю его на собственный файл. Использование инструмента для объединения всех ваших файлов для производства также является отличной идеей.
источник
module pattern
и он основан наIIFE pattern
.createNewSomething()
в возвращаемом объекте, чтобы создание объекта происходило исключительно внутри модуля? Хм ... я бы ожидал, что классы (конструкторы) видны снаружи.Я стараюсь избегать включения любого JavaScript в HTML. Весь код инкапсулирован в классы, и каждый класс находится в своем собственном файле. Для разработки у меня есть отдельные теги <script> для включения каждого файла js, но они объединяются в один большой пакет для производства, чтобы уменьшить накладные расходы на HTTP-запросы.
Как правило, у меня будет один «основной» js-файл для каждого приложения. Итак, если бы я писал «опросное» приложение, у меня был бы js-файл с именем «survey.js». Это будет содержать точку входа в код jQuery. Я создаю ссылки jQuery во время создания экземпляра, а затем передаю их в мои объекты в качестве параметров. Это означает, что классы javascript являются «чистыми» и не содержат ссылок на идентификаторы CSS или имена классов.
Я также считаю, что соглашение об именовании важно для удобства чтения. Например: я добавляю 'j' ко всем экземплярам jQuery.
В приведенном выше примере есть класс с именем DimScreen. (Предположим, что приглушается экран и появляется окно с предупреждением.) Ему нужен элемент div, который можно увеличить, чтобы покрыть экран, а затем добавить окно с предупреждением, поэтому я передаю объект jQuery. У jQuery есть концепция плагинов, но она казалась ограничивающей (например, экземпляры не являются постоянными и недоступными) без реального преимущества. Таким образом, класс DimScreen будет стандартным классом javascript, который просто использует jQuery.
Я построил несколько довольно сложных приложений, используя этот подход.
источник
$
префикса имени переменной является более распространенной практикой, но я могу ошибаться. Так что$s = $('...')
вместо этогоjS = $('...')
я предпочитаю просто вопрос предпочтений. Интересно, хотя, так как венгерская нотация считается запахом кода. Странно, насколько некоторые из моих соглашений / предпочтений кода JavaScript отличаются от моих соглашений о кодировании C # / Java.Systems Hungarian
это запахом кода иApps Hungarian
практикой :)var
, теперь, когда я думаю об этом. Большинство аргументов против использованияvar
- это когда вы не будете уверены в «типе» того, что возвращается, но я думаю, что аргумент должен быть против того, чтобы не знать «класс» того, что возвращается. Если вы используете Apps Hungarian, у вас не должно быть этой проблемы, тогда ... интересно.Вы можете разбить свои сценарии на отдельные файлы для разработки, а затем создать «релизную» версию, в которой вы соберете их все вместе и запустите YUI Compressor или что-то подобное на нем.
источник
Вдохновленный ранее посты , которые я сделал копию Rakefile и поставщика каталогов , распределенных с WysiHat (а RTE упомянутый журнал изменений) и сделал несколько изменений , чтобы включить код проверки с JSLint и Минимизация с YUI Compressor .
Идея состоит в том, чтобы использовать Sprockets (из WysiHat) для объединения нескольких сценариев JavaScripts в один файл, проверить синтаксис объединенного файла с помощью JSLint и минимизировать его с помощью YUI Compressor перед распространением.
Предпосылки
Сейчас делаю
Теперь создайте файл с именем «Rakefile» в корневом каталоге проекта JavaScript и добавьте в него следующее содержимое:
Если вы все сделали правильно, вы сможете использовать в консоли следующие команды:
rake merge
- объединить разные файлы JavaScript в одинrake check
- проверить синтаксис вашего кода (это задание по умолчанию , поэтому вы можете просто набратьrake
)rake minify
- подготовить минимизированную версию вашего JS-кодаПо слиянию источников
Используя Sprockets, препроцессор JavaScript, вы можете включать (или
require
) другие файлы JavaScript. Используйте следующий синтаксис для включения других сценариев из исходного файла (с именем «main.js», но вы можете изменить это в Rakefile):А потом...
Взгляните на Rakefile, поставляемый с WysiHat, чтобы настроить автоматическое модульное тестирование. Хороший материал :)
А теперь ответ
Это не очень хорошо отвечает на исходный вопрос. Я знаю и сожалею об этом, но я разместил это здесь, потому что я надеюсь, что кому-то еще будет полезно организовать их беспорядок.
Мой подход к проблеме состоит в том, чтобы сделать как можно больше объектно-ориентированного моделирования и разделить реализации на разные файлы. Тогда обработчики должны быть максимально короткими. Пример с
List
синглтоном тоже хорош.И пространства имен ... ну, они могут быть имитированы более глубокой структурой объекта.
Я не большой поклонник имитаций, но это может быть полезно, если у вас есть много объектов, которые вы хотели бы вывести из глобальной области видимости.
источник
Организация кода требует принятия соглашений и стандартов документации:
1. Код пространства имен для физического файла;
2. Групповые занятия в этих пространствах имен javascript;
3. Установите прототипы или связанные функции или классы для представления объектов реального мира;
4. Установите соглашения для улучшения кода. Например, сгруппируйте все свои внутренние функции или методы в его атрибуте class типа объекта.
5. Составьте документацию о пространствах имен, классах, методах и переменных. При необходимости также обсудите часть кода (некоторые FI и Fors, как правило, реализуют важную логику кода).
Это всего лишь несколько советов, но это очень помогло в организации кода. Помните, что вы должны иметь дисциплину, чтобы добиться успеха!
источник
Следование хорошим принципам проектирования ОО и шаблонам проектирования значительно облегчает поддержку и понимание вашего кода. Но одна из лучших вещей, которые я обнаружил в последнее время, это сигналы и слоты, также известные как публикация / подписка. Взгляните на http://markdotmeyer.blogspot.com/2008/09/jquery-publish-subscribe.html для простой реализации jQuery.
Идея хорошо используется на других языках для разработки GUI. Когда что-то существенное происходит где-то в вашем коде, вы публикуете глобальное синтетическое событие, на которое могут подписаться другие методы в других объектах. Это дает отличное разделение объектов.
Я думаю, что Dojo (и Prototype?) Имеют встроенную версию этой техники.
см. также Что такое сигналы и слоты?
источник
Мне удалось успешно применить шаблон модуля Javascript к приложению Ext JS на моей предыдущей работе. Он предоставил простой способ создания красиво инкапсулированного кода.
источник
У Dojo была модульная система с самого первого дня. На самом деле он считается краеугольным камнем Додзё, клея, который скрепляет все это:
Использование модулей Dojo позволяет достичь следующих целей:
dojo.declare()
) - не загрязняют глобальное пространство, сосуществуют с другими библиотеками и пользовательским кодом, не поддерживающим Dojo.dojo.require()
).источник
Проверьте JavasciptMVC .
Вы можете :
разделите ваш код на уровни модели, вида и контроллера.
сжать весь код в один производственный файл
автоматически генерировать код
создавать и запускать юнит-тесты
и многое другое ...
Лучше всего то, что он использует jQuery, поэтому вы также можете воспользоваться другими плагинами jQuery.
источник
Мой босс все еще говорит о временах, когда они писали модульный код (язык C), и жалуется на то, насколько дрянным является код в наши дни! Говорят, что программисты могут писать ассемблер в любой среде. Всегда есть стратегия преодоления организации кода. Основная проблема с парнями, которые рассматривают java-скрипт как игрушку и никогда не пытаются его изучить.
В моем случае я пишу js-файлы на основе темы пользовательского интерфейса или экрана приложения с надлежащим init_screen (). Используя правильное соглашение об именах идентификаторов, я удостоверяюсь, что на уровне корневых элементов нет конфликтов пространства имен. В ненавязчивом window.load () я связываю вещи на основе идентификатора верхнего уровня.
Я строго использую закрытия и шаблоны java-скриптов, чтобы скрыть все частные методы. После этого никогда не сталкивался с проблемой конфликтующих свойств / определений функций / определений переменных. Тем не менее, при работе с командой часто бывает трудно обеспечить одинаковую строгость.
источник
Я удивлен, что никто не упомянул фреймворки MVC. Я использовал Backbone.js для модульной и развязки своего кода, и это было неоценимо.
Существует довольно много подобных фреймворков, и большинство из них тоже довольно крошечные. Мое личное мнение таково: если вы собираетесь писать больше, чем просто пару строк jQuery для ярких элементов пользовательского интерфейса, или хотите использовать богатое Ajax-приложение, инфраструктура MVC сделает вашу жизнь намного проще.
источник
«Писать как сумасшедший и просто надеяться, что у него получится лучше?», Я видел такой проект, который был разработан и поддержан всего двумя разработчиками, огромное приложение с большим количеством кода JavaScript. Кроме того, для каждой возможной функции jquery были разные ярлыки. Я предложил, чтобы они организовали код как плагины, так как это эквивалент jquery класса, модуля, пространства имен ... и всей вселенной. Но все стало намного хуже, теперь они начали писать плагины, заменяя каждую комбинацию из 3 строк кода, используемых в проекте. Лично я думаю, что jQuery - это дьявол, и его не следует использовать в проектах с большим количеством javascript, потому что он поощряет вас быть ленивым и не думать об организации кода каким-либо образом. Я предпочел бы прочитать 100 строк JavaScript, чем одну строку с 40 связанными функциями jQuery (я я не шучу) Вопреки распространенному мнению, очень легко организовать код JavaScript в эквивалентах пространств имен и классов. Это то, что делают YUI и Dojo. Вы можете легко бросить свой собственный, если хотите. Я считаю, что подход YUI намного лучше и эффективнее. Но вам обычно нужен хороший редактор с поддержкой фрагментов, чтобы компенсировать соглашения об именах YUI, если вы хотите написать что-нибудь полезное.
источник
Я создаю синглтоны для каждой вещи, которую мне действительно не нужно создавать несколько раз на экране, классы для всего остального. И все они помещены в одно пространство имен в одном файле. Все комментируется и разрабатывается с помощью UML, диаграмм состояний. Код javascript не содержит html, поэтому нет встроенного javascript, и я склонен использовать jquery, чтобы минимизировать проблемы между браузерами.
источник
В моем последнем проекте - Viajeros.com - я использовал комбинацию нескольких методов. Я не знаю, как организовать веб-приложение - Viajeros - это сайт социальной сети для путешественников с четко определенными разделами, поэтому код для каждой области легко разделить.
Я использую имитацию пространства имен и ленивую загрузку модулей в соответствии с разделом сайта. На каждой странице загрузки я объявляю объект "vjr" и всегда загружаю в него набор общих функций (vjr.base.js). Затем каждая HTML-страница решает, какие модули нужны, с помощью простого:
Vjr.base.js получает каждый gzip-файл с сервера и выполняет их.
Каждый «модуль» имеет такую структуру:
Учитывая мои ограниченные знания Javascript, я знаю, что должны быть лучшие способы справиться с этим, но до сих пор это прекрасно работает для нас.
источник
Организация вашего кода в JS-образе, ориентированная на NameSpace, может выглядеть следующим образом ... и не будет конфликтовать с другими API Javascript, такими как Prototype, Ext.
Надеюсь это поможет.
источник
jQuery.fn
является указателем наjQuery.prototype
, потому что$()
фактически возвращает новый экземпляр функции конструктора jQuery. Добавление «плагина» в jQuery означает просто расширение его прототипа. Но то, что вы делаете, это не так, и есть более чистые способы сделать то же самое.Хороший принцип OO + MVC определенно будет иметь большое значение для управления сложным приложением javascript.
По сути, я систематизирую свое приложение и javascript со следующим знакомым дизайном (который существует еще со времен моего рабочего стола до Web 2.0)
Описание для числовых значений на изображении:
В прошлом я разделял файлы на свои собственные js и использовал обычную практику для создания принципов ОО в Javascript. Проблема, которую я вскоре обнаружил, состоит в том, что есть несколько способов написания JS OO, и это не обязательно, что у всех членов команды одинаковый подход. По мере того, как команда становилась все больше (в моем случае более 15 человек), это усложняется, так как нет стандартного подхода к объектно-ориентированному Javascript. В то же время я не хочу писать свою собственную структуру и повторять некоторые работы, которые, я уверен, умнее людей, чем я решил.
jQuery невероятно хорош как Javascript Framework, и мне это нравится, однако, по мере того, как проект становится больше, мне явно нужна дополнительная структура для моего веб-приложения, особенно для упрощения стандартизации практики ОО. Для себя после нескольких экспериментов нахожу, что YUI3 Base и Widget ( http://yuilibrary.com/yui/docs/widget/ и http://yuilibrary.com/yui/docs/base/index.html ) обеспечивает именно то, что мне нужно. Несколько причин, почему я их использую.
Вопреки многим представлениям, мне не обязательно выбирать между jQuery и YUI3. Эти двое могут мирно сосуществовать. Хотя YUI3 предоставляет необходимый шаблон OO для моего сложного веб-приложения, jQuery по-прежнему предоставляет моей команде простую в использовании абстракцию JS, которую мы все любим и знакомы.
Используя YUI3, мне удалось создать шаблон MVC, разделив классы, расширяющие базу как модель, классы, расширяющие виджет как представление, и, конечно, у вас есть классы контроллеров, которые выполняют необходимую логику и вызовы на стороне сервера.
Виджет может общаться друг с другом, используя модель, основанную на событиях, и прослушивая событие и выполняя необходимую задачу на основе предопределенного интерфейса. Проще говоря, размещение структуры OO + MVC в JS является для меня радостью.
Просто отказ от ответственности, я не работаю на Yahoo! и просто архитектор, который пытается справиться с той же проблемой, что и исходный вопрос. Я думаю, что если кто-нибудь найдет эквивалентную структуру OO, это также сработает В принципе, этот вопрос относится и к другим технологиям. Слава Богу за всех людей, которые придумали OO Principles + MVC, чтобы сделать наши дни программирования более управляемыми.
источник
Я использую управление пакетами (
dojo.require
иdojo.provide
) Dojo и систему классов (dojo.declare
которая также допускает простое множественное наследование), чтобы модульно преобразовать все мои классы / виджеты в отдельные файлы. Это не только позволяет сохранить ваш код организованным, но и позволяет выполнять ленивую / своевременную загрузку классов / виджетов.источник
Несколько дней назад ребята из 37Signals выпустили RTE-контроль с изюминкой. Они создали библиотеку, которая связывает файлы javascript с помощью команд препроцессора.
С тех пор я использую его для разделения моих файлов JS, а затем, в конце концов, объединяю их в один. Таким образом, я могу разделить проблемы и, в конце концов, иметь только один файл, который проходит через канал (gzipped, не меньше).
В своих шаблонах проверьте, находитесь ли вы в режиме разработки, и включите ли вы отдельные файлы, и, если вы работаете, включите последний (который вам придется «создавать» самостоятельно).
источник
Создайте фальшивые классы и убедитесь, что все, что может быть добавлено в отдельную функцию, которая имеет смысл, сделано именно так. Также убедитесь, что вы много комментируете, и не пишите спагетти-код, а храните его в разделах. Например, какой-то бессмысленный код, изображающий мои идеалы. Очевидно, в реальной жизни я также пишу много библиотек, которые в основном охватывают их функциональность.
источник
Используйте шаблоны наследования для организации больших приложений jQuery.
источник
Я думаю, что это связано, возможно, с DDD (Domain-Driven Design). Приложение, над которым я работаю, хотя и не имеет формального API, намекает на это с помощью кода на стороне сервера (имена классов / файлов и т. Д.). Вооружившись этим, я создал объект верхнего уровня в качестве контейнера для всей проблемной области; Затем я добавил пространства имен, где это необходимо:
источник
Для организации JavaScript используется следующее
источник
Я использую эту маленькую вещь. Он дает вам директиву include для шаблонов JS и HTML. Это полностью устраняет беспорядок.
https://github.com/gaperton/include.js/
источник
Вы можете использовать jquery mx (используется в javascriptMVC), который представляет собой набор скриптов, который позволяет вам использовать модели, представления и контроллеры. Я использовал его в проекте и помог мне создать структурированный javascript с минимальными размерами сценариев из-за сжатия. Это пример контроллера:
Вы также можете использовать только сторону контроллера jquerymx, если вас не интересуют вид и части модели.
источник
Твой вопрос мучил меня в конце прошлого года. Разница - передача кода новым разработчикам, которые никогда не слышали о частных и публичных методах. Мне пришлось построить что-то простое.
Конечным результатом была небольшая (около 1 КБ) инфраструктура, которая переводит объектные литералы в jQuery. Синтаксис визуально легче сканировать, и если ваш js становится действительно большим, вы можете написать повторно используемые запросы, чтобы найти такие вещи, как используемые селекторы, загруженные файлы, зависимые функции и т. Д.
Публиковать небольшие рамки здесь непрактично, поэтому я написал пост в блоге с примерами (Мое первое. Это было приключение!). Вы можете посмотреть.
Для любых других здесь с несколькими минутами, чтобы проверить это, я был бы очень признателен за обратную связь!
Рекомендуется FireFox, так как он поддерживает toSource () для примера запроса объекта.
Ура!
Адам
источник
Я использую собственный сценарий, вдохновленный поведением Бена Нолана (к сожалению, больше не могу найти текущую ссылку на это), чтобы хранить большинство моих обработчиков событий. Эти обработчики событий запускаются, например, элементами className или Id. Пример:
Мне нравится включать большинство моих библиотек Javascript на лету, кроме тех, которые содержат глобальное поведение. Для этого я использую помощник заполнителя headScript () Zend Framework , но вы также можете использовать javascript для загрузки других скриптов на лету, например, с помощью Ajile .
источник
Вы не упоминаете, какой у вас язык на стороне сервера. Или, более уместно, какую платформу вы используете - если таковая имеется - на стороне сервера.
IME, я организую вещи на стороне сервера и позволяю всему этому трястись на веб-странице. Фреймворку дана задача организовать не только JS, который должна загружать каждая страница, но и JS-фрагменты, которые работают с сгенерированной разметкой. Такие фрагменты, которые вы обычно не хотите, генерируются более одного раза - вот почему они абстрагируются в структуру для того, чтобы этот код заботился об этой проблеме. :-)
Для конечных страниц, которые должны испускать свой собственный JS, я обычно нахожу, что в сгенерированной разметке есть логическая структура. Такие локализованные JS часто могут быть собраны в начале и / или конце такой структуры.
Обратите внимание, что ничто из этого не освобождает вас от написания эффективного JavaScript! :-)
источник
Ленивый Загрузить нужный код по требованию. Google делает что-то подобное со своим google.loader
источник