Страничные файлы JavaScript в Rails 3.1 - PullRequest
Новая
       26

Страничные файлы JavaScript в Rails 3.1

1 голос
/ 13 декабря 2011

Я проводил исследования по этому вопросу:

Используя Rails 3.1, куда вы помещаете свой "специфичный для страницы" код JavaScript?

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

Вот моя ментальная модель: для разных взглядов у меня будут разные 

$(document).ready(....)

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

Моя интуиция, по общему признанию, не подкрепленная никакими предварительными экспериментами, заключается в том, что идеальным вариантом было бы:

  1. Загрузка кода приложения из application.js.
  2. Загрузка кода общего контроллера из чего-то вроде assets / controller_name / shared.js
  3. Загрузка кода, специфичного для вида, из чего-то вроде assets / controller_name / show.js

С верхней части моей головы.Помощник, при первом запуске, проверит, существует ли файл и, если это так, сделает для него javascript_include.

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

Однако, как и выше, я чувствую, что что-то упустил.Является ли $ (document) .ready для каждой страницы плохой идеей?Должно ли это быть в шаблоне и вызывать специфический для страницы бит JS из application.js?Приведенная выше статья приводит к такому выводу, но мне не нравится изображение, которое я получаю в голове из одного огромного $ (документа). Уже изобилующего, если это, если это, если другая вещь.

Ответы [ 2 ]

1 голос
/ 15 декабря 2012

Фон

(Зачем вообще использовать конвейер активов?)

Одной из основных предпосылок конвейера ресурсов Rails является идея о том, что предпочтительно загружать все JS и CSS для сайта один раз, а затем кэшировать их бесконечно (по крайней мере, до тех пор, пока сайт не будет обновлен). Конвейер активов позволяет вам делать это относительно автоматически, в то же время логически упорядочивая файлы JS и CSS src.

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

Орех проблемы

Хорошо, поэтому мы хотим объединить все наши JS в один файл, чтобы загрузить его более эффективно. Тот факт, что мы собираемся загрузить всех наших JS, не означает, что мы хотим запустить всех наших JS.

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

Конвенция о спасении

Мне не известна официальная стратегия Rails, чтобы справиться с этим, но есть несколько отличных решений, которые устанавливают и затем используют хорошее соглашение (которое заставляет вещи чувствовать себя "Rails"). Общая идея состоит в том, чтобы определить весь JS-код вашей страницы в литерал объекта, а затем запустить только код, соответствующий текущей странице при загрузке.

Подробную информацию о том, как организовать и условно выполнить ваш код JS, см. В ответе @ welldan97 на этот вопрос:
Используя Rails 3.1, куда вы помещаете свой "специфичный для страницы" код JavaScript?

, который в свою очередь основан на этой статье Джейсона Гарбера:
http://viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution

1 голос
/ 13 декабря 2011

То, что вы предлагаете, это звук, но не путь рельсов 3.1.

Они говорят, что разделяют JS на множество файлов, но служат для пользователя одним целым.Это обеспечивает лучшую производительность и масштабируемость, поэтому хорошо, если последний большой кусок грязи не такой большой.Действительно, 3 http-запроса дают худшую производительность, чем 1 http-запрос.

Итак, вы уже дипартизировали свой код, потому что у вас есть разные файлы Coffeescript с разными областями действия.

Для загрузки в ваше приложение,просто стандартизируйте способ инициализации отдельного фрагмента кода, например, вызов метода «myapp.users.init ()» -.

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

...