Максим Федоров, мне проще поддерживать и тестировать компоненты вообще без состояний. Компоненты со своими состояниями это как грязные функции — пропадает ощущение контроля над поведением приложения.
Мне не понятно почему хорошо, что компонент чёрный ящик. Это ведь усложняет отладку. То бишь если что-то пойдёт не так в каком-то сценарии где участвует этот компонент всё равно понадобится отлаживать и работу с его состоянием тоже. В чём выгода?
Алексей, уточни чем не угодил этот слайдер и что будет если оставить его и не менять? Например им неудобно пользоваться и клиенты не могут посмотреть фотки, падает конверсия. Так будет проще подсказать что-то стоящее
Блин, вот так понятнее, спасибо) param в another может действительно не быть и присваивание значения и есть создание param Похоже на то, что интерпретатор в JS разбирает вложенные ключи каким-то рекурсивным способом и применяет к ним ту же логику, что и к ключам верхнего уровня. То бишь если объекта родителя нет, то и присвоить некуда (создать негде). Теперь понятно в чём разница. Да это то, что нужно — меня интересовала работа этого кода под капотом.
Очередное напоминание насколько круто работает мозг людей воспринимая и упрощая сложные абстракции (я вижу объект целиком как единицу смысла и удивляюсь почему бы не создать промежуточный ключ) и насколько всё уныло устроено в компьютерах
Пока решил проблему вынеся сайдбар в отдельный компонент и подключая его в компонентах-страницах. Теперь интересно — насколько это "православное" решение?
Пытаюсь понять верно ли я понимаю. Например у меня есть компонент Dog, которому понадобилось задать поведение Murder и Robot, ангуляр-версия будет такой: . Если понадобится добавить другое поведение, то я могу описать его в директиве и просто дописать его в шаблон: . Верно ли, что в случае с реактом понадобится делать композицию из нужных компонентов?
Сергей Протько, стоит убать галп и заменить его на webpack? То бишь смогу я webpack'ом сначала сделать бандл глобальных модулей и объявить его точкой входа для commonJS?
