Comments 28
мне кажется, было бы куда конструктивнее, если бы вы рассказали о самой библиотеке github.com/ccampbell/mousetrap, не входя в контекст Rails.
-2
Мне кажется, что если человек ни разу не писал .keyup, то рассказ о библиотеке не помог бы. В остальном, библиотека прозрачна и лаконична. Интересно как-раз использование библиотеки как gem-а.
Оборачивать полезные библиотеки в gem-ы, достойная деятельность Rails разработчика.
Оборачивать полезные библиотеки в gem-ы, достойная деятельность Rails разработчика.
+1
Согласен (= Bundler наше все даже в управлении клиентскими JS библиотеками.
+1
Пора научиться это делать без обёрток под каждый чих. Думаю, фанаты Node.js тоже оценили бы.
0
А что плохого в обертках, если по сути они представляют из себя vendor каталог с JS библиотекой, и почти никак не нагружают приложение. Зато проблема обновления библиотеки (если таковая нужда имеется), может быть автоматизирована — если гем конечно поддерживать будут и обновлять в соответствии с релизами самой JS библиотеки.
0
Проблема в том, что эти обёртки (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']
}
0
В итоге у себя в проекте нужно было бы прописать JS.dep с указанием зависимостей с версиями, а нечто вроде универсального гема bundle-js предоставляло бы нужный набор файлов в asset pipeline, занималось бы фиксированием версий/ревизий в JS.lock.
Можно даже упросить, повесив на asset pipeline ответственность за минимизацию js/css.
Можно даже упросить, повесив на asset pipeline ответственность за минимизацию js/css.
0
Конечно, нужно создавать и поддерживать.
Не уверен, что для джема нужен файл-описание либы.
1. Версия лежит в стандартном
2. Окружения (прекомпиляция и минимизация ассетов) — забота рельсы.
3. Депенды есть в джемспеке.
Не уверен, что для джема нужен файл-описание либы.
1. Версия лежит в стандартном
mousetrap-rails / lib / mousetrap-rails / version.rb
и видна при установке бандлером.2. Окружения (прекомпиляция и минимизация ассетов) — забота рельсы.
3. Депенды есть в джемспеке.
0
И что делать, если мейнтейнер решил этот gem/npm больше не поддерживать, и навсегда ушёл в Java/C#, забив на GitHub/RubyGems?
twitter-bootstrap-rails и то с завидной нерегулярностью обновляется. А так бы это было на совести самих создателей JS библиотек/CSS фреймворков итп.
twitter-bootstrap-rails и то с завидной нерегулярностью обновляется. А так бы это было на совести самих создателей JS библиотек/CSS фреймворков итп.
0
Без сомнения, такое возможно.
Но никто не мешает сделать форк желающим и продолжить развитие либы. У меня в проектах довольно много собирается не с rubygems, а, например с github-форков этих джемов.
Этот вопрос скорее к комьюнити и мейнтейнерам. Если человек ответственный, то передаст права на джем желающим.
Но никто не мешает сделать форк желающим и продолжить развитие либы. У меня в проектах довольно много собирается не с rubygems, а, например с github-форков этих джемов.
Этот вопрос скорее к комьюнити и мейнтейнерам. Если человек ответственный, то передаст права на джем желающим.
+1
ну можно сколько угодно истерить, что мол так вот плохо, мейнтейнер ушел. форкнул и подключил в Gemfile через github к примеру. What's problem?
В чем смысл городить внутри и без того огромных Rails, еще пакетный менеджер под sprockets для JS библиотек, которых редко насчитывается на проекте больше 2-3 (берем средние проекты, а не огромные, коих процент куда ниже). В рельсах много чего есть, но то что там есть — действительно нужно. А вот такие финтоушастые навороты — лишнее. Обертка в виде минималистичного gem'а куда лучше.
В чем смысл городить внутри и без того огромных Rails, еще пакетный менеджер под sprockets для JS библиотек, которых редко насчитывается на проекте больше 2-3 (берем средние проекты, а не огромные, коих процент куда ниже). В рельсах много чего есть, но то что там есть — действительно нужно. А вот такие финтоушастые навороты — лишнее. Обертка в виде минималистичного gem'а куда лучше.
0
Не так и мало, а проект не так давно начался:
Плю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 хорошая идея, если их немного.
0
Это еще мало.
А куда их надо класть, прошу прощения?
А куда их надо класть, прошу прощения?
0
Честно, я понимаю ваше негодование. Но, давайте взглянем на то, какие у нас собственно альтернативы то:
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 брать хотя бы изначально.
Может я пропустил какой-то вариант, но из тех что я увидел — я выбрал меньшее из зол. Других решений более удобных в данной ситуации я просто не вижу и не знаю. Если я не знаю, но они есть — посыпаю голову пеплом и прошу поделиться и буду благодарен, честно и без сарказма.
+3
В общем я за ваше решение, но только при условии наличия вменяемого репозитория пакетов или мета-пакетов, и поддержки со стороны sprockets (пусть даже в виде отдельного гема).
+1
Немного оффтопная, но тем не менее заслуживающая внимания статья на близкую тему: Unholy Rails: External Scripts, jQuery Plugins, and Page-Specific JavaScript
0
Спасибо, автор!
0
UFO just landed and posted this here
Отличная картинка к статье!
PS: Статья тоже отличная ;)
PS: Статья тоже отличная ;)
0
Вы определитесь, о чём хотите рассказать.
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
-1
Я уверен, что если внимательно прочитать статью не менее пяти раз, то на вас снизойдет прозрение.
0
Что, за живое задел, не оценив работу?
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
0
Работы тут на выходной, так что отнюдь не задел.
Ваш пойнт понятнен, но кто-то любит арбуз, а кто-то свиной хрящик. Такими темпами можно дойти до ненужности языков с высоким уровнем абстракции.
Тем паче ситуация «хочу здесь и сейчас» изрядно высосана из пальца.
В любом случае, разве плохо, когда есть выбор? Хотите, пользуйтесь 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 в приложения. Будут полезные мысли — обращайтесь.
0
Sign up to leave a comment.
Articles
Change theme settings
Хоткеи в приложенях Ruby on Rails