В этом нет какой-либо опасности. Машина никак не реагирует, она просто продолжает катиться по инерции, как буд-то вы не держите ногу на педали газа. Разница только в том, что на нейтралке не будет происходить торможения двигателем.
На нейтралку на ходу конечно же можно переводить. Во всяком случае, пока что не встречал иномарок с автоматом, где этого сделать было бы нельзя или где коробка игнорировала бы такое переключение. На Тайотах такого точно не замечал.
Многие авто способы ехать даже с ручником, причем на некоторых авто двигатель настолько мощный, что ручник что есть, что его нет. Я так однажды целый день проездил с ручником, и только вечером заметил, что ручник-то взведен до упора (в моем случае был механический ручник)...
Стоит также отметить, что со времен написания статьи redux-simple-router был переименован в react-router-redux, routeReducer переименован в routerReducer, а syncHistory в syncHistoryWithStore.
Судя по отсутствию комментариев, интерес к JSON-LD весьма низок, не говоря уже о технологиях, использующих его.
Для себя еще не решел, есть ли у JSON-LD преимущества перед microdata. Но иногда складывается впечетление, что во многих веб-продутах все же проще пользоваться microdata, поскольку данные часто уже есть в текста самой страницы, в то время как с JSON-LD их нужно дублировать. Это выглядит особенно чудовищно, когда речь заходит о статьях, куски коих нужно дублировать в JSON-LD для получения желаемого эффекта.
Давно используем JSPM в своем проекте и тоже весьма довольны. К сожалению, правда, что JSPM не без своих недостатков. В частности, к организации конфигов и путей в бете 0.17 много вопросов...
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
Люди спрашивали, применим ли БЭМ для организации JS кода и насколько это эффективно. Это несколько иное. Или я что-то упускаю?
Из такого чейнинга при изучении html-кода совершенно непонятно, на что влияет класс `.is-new` — на `Article`? Или может быть на какой-то иной блок в данной html-ноде? Ведь на одной ноде может быть несколько блоков или элементов.
В случае наличия на одной html-ноде нескольких блоков это может привести к неприятным коллизиям.
БЭМ не только пытается решить проблему коллизий, но еще и проблему specifity. И вот такой вот чейнинг как раз возвращает эту проблему. И во многих местах она серьезней, чем кажется
Можно вернуть в ваш BEM немного CSS:
.Article.is-new .Article-title { color: red }
Это как раз в рамках методологии БЭМ. Если не ошибаюсь, называется уровнями переопределения, как раз для таких случаев — когда состояние блока контролирует вид его элементов. Реализуется оно либо именно так, как было сделанно в примере, либо так:
.article--is-new .article-title { color: red }
Однако стоит помнить, что такое переопределение в дальнейшем может принести множество проблем со specifity. Потому применять следует только в строго предписанных врачем количествах.
CamelCase нотация для блоков радует глаз заядлых си-плюс-плюсщиков/яваскриптистов/рубистов, а еще помогает никогда не путать блоки и элементы.
Я бы сказал, для классов используется kebab-case не потому, что он легче читается (это ведь субъективно), а просто как наследие самого html и css, которые как языки по умолчанию являются kebab-case (http-equiv, data-attribute в HTML, text-shadow, background-color в CSS). Консистентность.
По моему опыту, БЭМ в JS применим только как наследие от CSS, когда нужно работать с классами, имеющимися в верстке.
БЭМ в первую очередь борется с глобальными колизиями, проблемами specifity, отсутсвием нативной модульности. Мне кажется, избыточно пытаться применить эту методологию в языке, который не имеет таких проблем (при правильной организации кода).
Спасибо за пример. Проблема действительно имеет место быть.
Тем не менее, не могу не отметить, что BEM classname generator местами избыточно утрирует ситуацию. К примеру, многие генерируемые ним элементы должны быть раздельными блоками, что не только сокращает название в два раза, но и делает их портативными.
В модификаторах также крайне редко встречаются такие длинные названия.
В этом нет какой-либо опасности. Машина никак не реагирует, она просто продолжает катиться по инерции, как буд-то вы не держите ногу на педали газа. Разница только в том, что на нейтралке не будет происходить торможения двигателем.
На нейтралку на ходу конечно же можно переводить. Во всяком случае, пока что не встречал иномарок с автоматом, где этого сделать было бы нельзя или где коробка игнорировала бы такое переключение. На Тайотах такого точно не замечал.
Многие авто способы ехать даже с ручником, причем на некоторых авто двигатель настолько мощный, что ручник что есть, что его нет. Я так однажды целый день проездил с ручником, и только вечером заметил, что ручник-то взведен до упора (в моем случае был механический ручник)...
Стоит также отметить, что со времен написания статьи
redux-simple-routerбыл переименован в react-router-redux,routeReducerпереименован вrouterReducer, аsyncHistoryвsyncHistoryWithStore.И в целом, методика подключения
react-router-reduxнесколько изменилась.Спасибо за статью
Судя по отсутствию комментариев, интерес к JSON-LD весьма низок, не говоря уже о технологиях, использующих его.
Для себя еще не решел, есть ли у JSON-LD преимущества перед microdata. Но иногда складывается впечетление, что во многих веб-продутах все же проще пользоваться microdata, поскольку данные часто уже есть в текста самой страницы, в то время как с JSON-LD их нужно дублировать. Это выглядит особенно чудовищно, когда речь заходит о статьях, куски коих нужно дублировать в JSON-LD для получения желаемого эффекта.
Давно используем JSPM в своем проекте и тоже весьма довольны. К сожалению, правда, что JSPM не без своих недостатков. В частности, к организации конфигов и путей в бете 0.17 много вопросов...
standard с командой
--fixВам в помощьЛюди спрашивали, применим ли БЭМ для организации JS кода и насколько это эффективно. Это несколько иное. Или я что-то упускаю?
o-btn c-btn c-btn--positive qa-modal-acceptЗато это позволяет очень гранулированно использовать классы и конфигурировать практически что угодно на лету.
Такой подход используется в нашем фреймворке, который используется в нашем генераторе статических веб-сайтов\стартер-ките. Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.
Однако, я бы все таки воздержался от таких решений. Слишком много узких мест.
Здесь не все так гладко:
Это как раз в рамках методологии БЭМ. Если не ошибаюсь, называется уровнями переопределения, как раз для таких случаев — когда состояние блока контролирует вид его элементов. Реализуется оно либо именно так, как было сделанно в примере, либо так:
Однако стоит помнить, что такое переопределение в дальнейшем может принести множество проблем со specifity. Потому применять следует только в строго предписанных врачем количествах.
Я бы сказал, для классов используется kebab-case не потому, что он легче читается (это ведь субъективно), а просто как наследие самого html и css, которые как языки по умолчанию являются kebab-case (
http-equiv,data-attributeв HTML,text-shadow,background-colorв CSS). Консистентность.БЭМ в первую очередь борется с глобальными колизиями, проблемами specifity, отсутсвием нативной модульности. Мне кажется, избыточно пытаться применить эту методологию в языке, который не имеет таких проблем (при правильной организации кода).
Тем не менее, не могу не отметить, что BEM classname generator местами избыточно утрирует ситуацию. К примеру, многие генерируемые ним элементы должны быть раздельными блоками, что не только сокращает название в два раза, но и делает их портативными.
В модификаторах также крайне редко встречаются такие длинные названия.
И особенное спасибо за ответы на комментарии — они оказались ещё более познавательными, чем сама статья :)