Никита Гущин: Нет, не изменяю, сноска лишь говорит о том, что этого делать не стоит, но иммутабельность props - это, в первую очередь, соглашение, а не только техническое ограничение
Вы не смешивайте процесс разработки и "выкладки в продакшн". Вопрос стоял о workflow front-end разработки, после финальной стадии можете отдавать заказчику /заливать на хостинг
Можно еще использовать object spread syntax из ES7, поскольку Babel у вас подключен:
Тогда будет как-то так?
case LOAD_INFO:
return {...state, ...{ book: action.data.book, magazine: action.data.magazine }
};
Только в редьюсере должно быть как-то так:
case LOAD_INFO:
return Object.assign({}, state, {
book: action.data.book,
magazine: action.data.magazine
});
Да, это замечательный пакет, который пришел на смену classSet, как вариант декларативного описания сборки классов он тоже подойдет, но надо не забывать, что это лишняя зависимость.
У вас, кстати, пример нерабочий, как минимум, в FF. Использовать вендорные префиксы, привязанные к одному браузеру (-webkit-transition), не самый верный способ.
Артур Мудрик: т.е. наличие .block__header__icon вас не смущает, а класс-модификатор не дает покоя?
Проблем у вас нет, потому-что вы не используете БЭМ и даже то, что вы пишете руками, к БЭМ не имеет отношение
Артур Мудрик: и в чем проблема? Зачем вам отдельный элемент для иконки, когда можно вложить блок иконки непосредственно в элемент header? Можно добавить еще один модификатор, который будет настраивать иконку под конкретный блок.
◅div class="block"▻
◅div class="block__header"▻
◅i сlаss="icon icon_close icon_card-header"▻◅/i▻
◅/div▻
◅/div▻
Артур Мудрик: в данном случаи, иконки - это самостоятельные блоки, которые скорее всего будут использоваться на странице и в других блоках, поэтому, в соответствии с методологией БЭМ, блоки иконок можно представить так:
где icon - это базовый блок с дефотными значениями - url на спрайт или font-family шрифта, стандартными размерами и т.п., а icon_type_maximize - это блок уже с конкретным модификатором, где можно прописать необходимые background-position или content
Евгений Петров: формируют согласно спеки по следующим правилам:
"Since an element with opacity less than 1 is composited from a single offscreen image, content outside of it cannot be layered in z-order between pieces of content inside of it. For the same reason, implementations must create a new stacking context for any element with opacity less than 1. If an element with opacity less than 1 is not positioned, implementations must paint the layer it creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with ‘z-index: 0’ and ‘opacity: 1’. If an element with opacity less than 1 is positioned, the ‘z-index’ property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’ since a new stacking context is always created." www.w3.org/TR/css3-color/#transparency
