Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
мне кажется, было бы куда конструктивнее, если бы вы рассказали о самой библиотеке github.com/ccampbell/mousetrap, не входя в контекст Rails.
Мне кажется, что если человек ни разу не писал .keyup, то рассказ о библиотеке не помог бы. В остальном, библиотека прозрачна и лаконична. Интересно как-раз использование библиотеки как gem-а.
Оборачивать полезные библиотеки в gem-ы, достойная деятельность Rails разработчика.
Оборачивать полезные библиотеки в gem-ы, достойная деятельность Rails разработчика.
Согласен (= Bundler наше все даже в управлении клиентскими JS библиотеками.
Пора научиться это делать без обёрток под каждый чих. Думаю, фанаты Node.js тоже оценили бы.
А что плохого в обертках, если по сути они представляют из себя vendor каталог с JS библиотекой, и почти никак не нагружают приложение. Зато проблема обновления библиотеки (если таковая нужда имеется), может быть автоматизирована — если гем конечно поддерживать будут и обновлять в соответствии с релизами самой JS библиотеки.
Проблема в том, что эти обёртки (gem, npm) кому-то нужно создавать и поддерживать.
Было бы проще, если бы авторы библиотек клали в проект нечто вроде файла JS.dep примерно следующего формата:
Было бы проще, если бы авторы библиотек клали в проект нечто вроде файла JS.dep примерно следующего формата:
{
name: 'mousetrap',
provides: 'mousetrap', // Необязательное, а для Zepto.js, например, тут будет 'jquery'
conflicts: ['keymaster', 'keyboard_shortcuts'],
version: '1.0.2',
depends: {
'underscore': '1.3+',
'whatever': '1.1.x'
},
development: {
js: ['mousetrap.js', 'mousetrap-console.js'],
css: ['mousetrap.css']
},
production: {
js: 'mousetrap-min.js'
},
images: ['mousetrap.png']
}
В итоге у себя в проекте нужно было бы прописать JS.dep с указанием зависимостей с версиями, а нечто вроде универсального гема bundle-js предоставляло бы нужный набор файлов в asset pipeline, занималось бы фиксированием версий/ревизий в JS.lock.
Можно даже упросить, повесив на asset pipeline ответственность за минимизацию js/css.
Можно даже упросить, повесив на asset pipeline ответственность за минимизацию js/css.
В общем и целом все эти чудеса есть в джемспеке.
Конечно, нужно создавать и поддерживать.
Не уверен, что для джема нужен файл-описание либы.
1. Версия лежит в стандартном
2. Окружения (прекомпиляция и минимизация ассетов) — забота рельсы.
3. Депенды есть в джемспеке.
Не уверен, что для джема нужен файл-описание либы.
1. Версия лежит в стандартном
mousetrap-rails / lib / mousetrap-rails / version.rb и видна при установке бандлером.2. Окружения (прекомпиляция и минимизация ассетов) — забота рельсы.
3. Депенды есть в джемспеке.
И что делать, если мейнтейнер решил этот gem/npm больше не поддерживать, и навсегда ушёл в Java/C#, забив на GitHub/RubyGems?
twitter-bootstrap-rails и то с завидной нерегулярностью обновляется. А так бы это было на совести самих создателей JS библиотек/CSS фреймворков итп.
twitter-bootstrap-rails и то с завидной нерегулярностью обновляется. А так бы это было на совести самих создателей JS библиотек/CSS фреймворков итп.
Без сомнения, такое возможно.
Но никто не мешает сделать форк желающим и продолжить развитие либы. У меня в проектах довольно много собирается не с rubygems, а, например с github-форков этих джемов.
Этот вопрос скорее к комьюнити и мейнтейнерам. Если человек ответственный, то передаст права на джем желающим.
Но никто не мешает сделать форк желающим и продолжить развитие либы. У меня в проектах довольно много собирается не с rubygems, а, например с github-форков этих джемов.
Этот вопрос скорее к комьюнити и мейнтейнерам. Если человек ответственный, то передаст права на джем желающим.
ну можно сколько угодно истерить, что мол так вот плохо, мейнтейнер ушел. форкнул и подключил в Gemfile через github к примеру. What's problem?
В чем смысл городить внутри и без того огромных Rails, еще пакетный менеджер под sprockets для JS библиотек, которых редко насчитывается на проекте больше 2-3 (берем средние проекты, а не огромные, коих процент куда ниже). В рельсах много чего есть, но то что там есть — действительно нужно. А вот такие финтоушастые навороты — лишнее. Обертка в виде минималистичного gem'а куда лучше.
В чем смысл городить внутри и без того огромных Rails, еще пакетный менеджер под sprockets для JS библиотек, которых редко насчитывается на проекте больше 2-3 (берем средние проекты, а не огромные, коих процент куда ниже). В рельсах много чего есть, но то что там есть — действительно нужно. А вот такие финтоушастые навороты — лишнее. Обертка в виде минималистичного gem'а куда лучше.
Не так и мало, а проект не так давно начался:
Плюc ещё jquery-purr (через best-in-place), jquery-loadmask, jquery-maskedinput, jquery-placeholder, mediaelement и некоторое количество css'ов из непонятных источников. К сожалению для них соответствующих гемов не нашлось.
Если следовать вашей логике, так и класть библиотеки в /vendor хорошая идея, если их немного.
gem 'twitter-bootstrap-rails'
gem 'jquery-rails'
gem 'ios-checkboxes'
gem 'codemirror-rails'
gem 'highchart-rails'
gem 'underscore-rails'
gem 'bootstrap-datepicker-rails'
gem 'jshint_on_rails'
Плюc ещё jquery-purr (через best-in-place), jquery-loadmask, jquery-maskedinput, jquery-placeholder, mediaelement и некоторое количество css'ов из непонятных источников. К сожалению для них соответствующих гемов не нашлось.
Если следовать вашей логике, так и класть библиотеки в /vendor хорошая идея, если их немного.
Это еще мало.
А куда их надо класть, прошу прощения?
А куда их надо класть, прошу прощения?
Честно, я понимаю ваше негодование. Но, давайте взглянем на то, какие у нас собственно альтернативы то:
1) использовать gem'ы;
2) ложить в vendor;
3) JS.dep — как вы и предложили выше.
1) удобно, логично, и под контролем у Bundler. Никакой сторонней магии, и такие гемы могут быть легко включены в зависимости к каким-нить плагинам к рельсам (к примеру, фреймворк для админки с мордой на Bootstrap со всеми вытекающими);
2) ложить в вендор — ну вы, как и я понимаете — не выход, если только не плевать — обновляется ли библиотека или нет;
3) JS.dep — кажется самый идеальный вариант, даже если sprockets такое умел бы из коробки. Но у нас есть огромная проблема: где брать всю эту информацию о том, откуда библиотеку скачать, откуда скачать зависимости, и прочее прочее. Я смотрю на rubygems и там все шикарно. Смотрю на репозиторий пакетов npm — и там такая свалка. А нам нужен такой репозиторий для клиентских JS-библиотек. Если такой есть — скажите и покажите.
Ну и опять таки. Откуда эти вот JS.dep брать хотя бы изначально.
Может я пропустил какой-то вариант, но из тех что я увидел — я выбрал меньшее из зол. Других решений более удобных в данной ситуации я просто не вижу и не знаю. Если я не знаю, но они есть — посыпаю голову пеплом и прошу поделиться и буду благодарен, честно и без сарказма.
1) использовать gem'ы;
2) ложить в vendor;
3) JS.dep — как вы и предложили выше.
1) удобно, логично, и под контролем у Bundler. Никакой сторонней магии, и такие гемы могут быть легко включены в зависимости к каким-нить плагинам к рельсам (к примеру, фреймворк для админки с мордой на Bootstrap со всеми вытекающими);
2) ложить в вендор — ну вы, как и я понимаете — не выход, если только не плевать — обновляется ли библиотека или нет;
3) JS.dep — кажется самый идеальный вариант, даже если sprockets такое умел бы из коробки. Но у нас есть огромная проблема: где брать всю эту информацию о том, откуда библиотеку скачать, откуда скачать зависимости, и прочее прочее. Я смотрю на rubygems и там все шикарно. Смотрю на репозиторий пакетов npm — и там такая свалка. А нам нужен такой репозиторий для клиентских JS-библиотек. Если такой есть — скажите и покажите.
Ну и опять таки. Откуда эти вот JS.dep брать хотя бы изначально.
Может я пропустил какой-то вариант, но из тех что я увидел — я выбрал меньшее из зол. Других решений более удобных в данной ситуации я просто не вижу и не знаю. Если я не знаю, но они есть — посыпаю голову пеплом и прошу поделиться и буду благодарен, честно и без сарказма.
В общем я за ваше решение, но только при условии наличия вменяемого репозитория пакетов или мета-пакетов, и поддержки со стороны sprockets (пусть даже в виде отдельного гема).
Немного оффтопная, но тем не менее заслуживающая внимания статья на близкую тему: Unholy Rails: External Scripts, jQuery Plugins, and Page-Specific JavaScript
Повторять официальную документацию дело, как мне кажется, не очень благодарное.
Тем более небольшое интро библиотеки на хабре уже было.
Тем более небольшое интро библиотеки на хабре уже было.
Спасибо, автор!
Отличная картинка к статье!
PS: Статья тоже отличная ;)
PS: Статья тоже отличная ;)
Вы определитесь, о чём хотите рассказать.
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
Я уверен, что если внимательно прочитать статью не менее пяти раз, то на вас снизойдет прозрение.
Что, за живое задел, не оценив работу?
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
Работы тут на выходной, так что отнюдь не задел.
Ваш пойнт понятнен, но кто-то любит арбуз, а кто-то свиной хрящик. Такими темпами можно дойти до ненужности языков с высоким уровнем абстракции.
Тем паче ситуация «хочу здесь и сейчас» изрядно высосана из пальца.
В любом случае, разве плохо, когда есть выбор? Хотите, пользуйтесь js-библотекой от вендора, хотите — подключайте в более привычном для ruby виде — джемом.
Так или иначе gem я собираюсь развивать, добавляя js-хеперы для более простой и удобной интеграции Mousetrap в приложения. Будут полезные мысли — обращайтесь.
Ваш пойнт понятнен, но кто-то любит арбуз, а кто-то свиной хрящик. Такими темпами можно дойти до ненужности языков с высоким уровнем абстракции.
We have to recognize #Ruby's syntax — requiring roughly 10KLOC C parser code — as one of the truly catastrophic events of the last century© twitter.com/PLT_Zizek/status/193389385960534018
Тем паче ситуация «хочу здесь и сейчас» изрядно высосана из пальца.
В любом случае, разве плохо, когда есть выбор? Хотите, пользуйтесь js-библотекой от вендора, хотите — подключайте в более привычном для ruby виде — джемом.
Так или иначе gem я собираюсь развивать, добавляя js-хеперы для более простой и удобной интеграции Mousetrap в приложения. Будут полезные мысли — обращайтесь.
Промазал комментарием от избытка чувств Это, конечно, ответ хабраюзеру morr.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хоткеи в приложенях Ruby on Rails