В вашем написании код приходится читать дважды, в разных направлениях. Сначала сверху вниз, потому что это императивный язык, потом снизу вверх, чтобы вникнуть в логику.
rate от exchange rate, так вроде переводится обменный курс. Можно 2 слова писать, если в команде возникают недопонимания. По-моему, это лучше чем rubles_per_unit, т.к. не привязано к валюте. Ничего страшного в связи с rates не вижу, users.each { |user| ... } можно же писать.
Пропаганды не видел, скорее про это пишут в смысле "даже так вот можно". Сам же манки патчинг довольно удобен, особенно сейчас, когда очень много OSS. Часто либа может иметь баг или просто не иметь поддержки нужного функционала, которая решается добавлением пары строчек. Часто такие штуки фичи не нужны всем, только в одном приложении. В этой ситуации есть несколько решений:
сделать PR, и ждать когда примут и зарелизят,
форкнуть либу, и потом периодически рибэйзить на апстрим,
сделать манки патч, и пользоваться оригиналом.
Конечно, в зависимости от количества изменений 1й и 2й варианты могут быть предпочтительны. Но по мне 3й варинат лучше, если правок действительно немного. И манки патчинг в руби удобен (в жс вон что люди придумывают: https://github.com/jhnns/rewire).
Ну и плюс во время разработки. Можно проверить локально, переопределив сначала методы, проверить. А затем вернуться к 1му/2му варианту.
В оригинале в комментах пишут про clojure. Что на нём прототипирование по скорости сравнимо с рельсами. Подробнее не читал, может там и либы предлагают.
Что-то я сразу не подумал, про пути без хоста до картинок. Спасибо!
Вы markerclustererplus или markerclusterer используете? Для 2-го вроде должна работать опция MarkerClusterer.prototype.MARKER_CLUSTER_IMAGE_PATH_ = '/assets/img/markers/m'
Статику копировать и коммитить в public я не хотел, раз она уже есть в репозитории.
Пример странный вы привели. Сайт довольно простой (вщзможно, я не всё видел), каких-то сложных манипуляций с элементами на странице нет, в основном текстовый контент с картинками. При этом сервер выдает весь этот контент в своей кастомной разметке в json. Соответственно, под это у них еще 2 слоя: тот который на серве рендерит жсон, и тот который это парсит и рендерит в реакт. Вопрос: зачем так усложнять? pjax или turbolinks для этих целей вроде вполне бы хватило.
Спасибо за перевод! Понравилось то, что на кофе пишет.
Кто-нибудь пробовал react_on_rails с hot-reload и redux? Там по-сложнее все выглядит (отдельно собирать, webpack поднимать), но redux впечатляюще смотрится. Или оно того не стоит и эти фичи редко используются?
P.s. Странно, что он пробелы не вставлял между кнопками и инпутами — так бы они не слипались. Это особенность бутстрэпа, о которой надо помнить, работая с шаблонизаторами, убирающими пробелы.
и ведь в оригинале так на kremlin.ru. рукалицо
В вашем написании код приходится читать дважды, в разных направлениях. Сначала сверху вниз, потому что это императивный язык, потом снизу вверх, чтобы вникнуть в логику.
rateотexchange rate, так вроде переводитсяобменный курс. Можно 2 слова писать, если в команде возникают недопонимания. По-моему, это лучше чемrubles_per_unit, т.к. не привязано к валюте. Ничего страшного в связи сratesне вижу,users.each { |user| ... }можно же писать.Почему простой вариант не рассматривается даже? Все инкапсулированно, и лишние сущности не надо создавать.
Гем pry (debbie — тот же при, только с набором расширений), может очень помочь. Я без show-method, show-doc теперь как без рук.
Пропаганды не видел, скорее про это пишут в смысле "даже так вот можно". Сам же манки патчинг довольно удобен, особенно сейчас, когда очень много OSS. Часто либа может иметь баг или просто не иметь поддержки нужного функционала, которая решается добавлением пары строчек. Часто такие штуки фичи не нужны всем, только в одном приложении. В этой ситуации есть несколько решений:
Конечно, в зависимости от количества изменений 1й и 2й варианты могут быть предпочтительны. Но по мне 3й варинат лучше, если правок действительно немного. И манки патчинг в руби удобен (в жс вон что люди придумывают: https://github.com/jhnns/rewire).
Ну и плюс во время разработки. Можно проверить локально, переопределив сначала методы, проверить. А затем вернуться к 1му/2му варианту.
В оригинале в комментах пишут про clojure. Что на нём прототипирование по скорости сравнимо с рельсами. Подробнее не читал, может там и либы предлагают.
Сложнее же получается, нет?
https://github.com/googlemaps/js-marker-clusterer/blob/gh-pages/src/markerclusterer.js#L190
По-умолчанию всё ещё с гуглкода раздаётся :)
Что-то я сразу не подумал, про пути без хоста до картинок. Спасибо!
Вы markerclustererplus или markerclusterer используете? Для 2-го вроде должна работать опция
MarkerClusterer.prototype.MARKER_CLUSTER_IMAGE_PATH_ = '/assets/img/markers/m'Статику копировать и коммитить в
publicя не хотел, раз она уже есть в репозитории.Открыл адрес, который вы указали. При переходе по ссылкам во вкладке "Сеть" в ответах вижу
У меня пока сомнения насчёт таких SPA.
А если нужен рендеринг на серве? Или часть страниц без реакта. Несовсем понятно в таком случае, где лэйауты и стили хранить.
Кто-нибудь пробовал react_on_rails с hot-reload и redux? Там по-сложнее все выглядит (отдельно собирать, webpack поднимать), но redux впечатляюще смотрится. Или оно того не стоит и эти фичи редко используются?
P.s. Странно, что он пробелы не вставлял между кнопками и инпутами — так бы они не слипались. Это особенность бутстрэпа, о которой надо помнить, работая с шаблонизаторами, убирающими пробелы.
required: true, да и можно поменять это значение сRails.application.config.active_record.belongs_to_required_by_default.https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations/builder/belongs_to.rb#L126-L136
required: trueвместоpresenceвалидатора: