У меня есть идея о том как распределять js/coffee файлы в Rails приложениях, тех что не SPA. Правда пока не пробовал его в бою) но тем не менее мне, он кажется перспективным.
Основной посыл в том чтобы браузер загружал и использовал только те скрипты, которые используются в рамках одного action. Точнее даже так один action – один js файл.
Как пример, один layout с применением этого подхода:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
doctype html html head title | LunchMap = csrf_meta_tags = stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' body = yield script[src="https://maps.googleapis.com/maps/api/js?key=AIzaSyCGkrcc3K51MYzz53tqXtewcTiaVPG7rg0"] = javascript_include_tag 'vendor', = javascript_include_tag 'base' = javascript_include_tag asset_path("#{controller_name}/#{action_name}") |
vendor – набор основных библиотек, которые скорее всего пригодятся на каждой странице. Для меня таковыми являются: jquery, moment.js, lodash.base – это уже часть приложения, основные функции необходимые на большинстве страниц. Какие-то общие event handlers.asset_path("#{controller_name}/#{action_name}") – код отвечающий за страницу, и необходимые для этой конкретной страницы vendor библиотеки.
Такая структура потребует хранить файлы в строгом порядке, но как мне кажется это больше плюс.
Например, страница редактирования Post, app/controllers/posts_controllers.rb и action edit, соответствует файл app/assets/javascripts/posts/edit.coffee.
У такого подхода есть как преимущества, так и недостатки. Начну с недостатков, их всё таки меньше:
- Обязательное создание файлов, для каждого action (те что рендерятс). Но, справедливости ради, большинство страниц, всё же и так требуют js. Так что, ничего страшного.
А вот преимущества на мой взгляд перевешивают недостатки:
- Нет даже намёка на глобальную область видимости. Это пожалуй самое крутое.
- Сокращение времени на парсинг и скриптинг браузером.
- Естественно меньший объём js, что означает высокую скорость загрузки.
Что думаете?)