И все-таки, вот так работает :) Работает конечно, я говорил, что спецификация рекомендует пропсы в конструкторе объявлять ).

Действительно очень нужный инструмент. Позволяет навести порядок в запросах к серверу

И все-таки, вот так работает :)

Чтобы в чанках работали конструкции типа {field name=blabla}, посмотрите в сторону fenom. Они со смарти вполне уживаются вместе. Но работу не могу гарантировать, так как моменты выполнения у смарти и фенома разные. То есть может заработать, а может и нет.

в чанках {field name...} и не будет работать, поскольку это тег Smarty. Насколько я помню, shopkeeper позволяет указывать tpl-файлы вместо чанков. Но это лучше уточнить на сайте разработчика shopkeeper

Подскажите, как запустит смарти с shopkeeper и tagManager 2? Вывод товаров сделал, по примеру выше, но, при обработке фильтра, выходит массив с документами и не подгружает шаблон :-( Я пробовал так, взял запуск через {snippet name=tmCatalog} вроде работает, пришлось прописать чанк для этого. Но, в чанках не работает конкструкция {field name=blabla} как тогда заставить сие работать?

а редьюсер по сути своей не меняет старый стор...а создает новый объект и копирует в него информацию из старого...получается мы заменяем кусок стора полностью... Вот как раз это копирование мне очень сильно не нравится по двум описанным выше причинам.

Николай, я лично не вижу ничего ужасного в использовании SCU(shouldComponentUpdate). Так я тоже не имею ничего против. Но я сторонник того, чтобы средства оптимизации оставлять на потом, когда реально возникнет необходимость. Если уже сейчас вы используете все средства оптимизации, то что вы сделаете тогда, когда производительность будет низкая, а все средства уже использованы? Второй момент: разрастается код и усложняется процесс. Этот механизм - очень тонкий, и приходится много условий прописывать. Если еще сложные связи, то вообще. Я вот сторонник того, чтобы кода было как можно меньше.

я вот хоть и реализовал несколько проектов на реакте все равно не могу пока понять одного...а зачем иммутабельный стор? в моем случае после того как диспатчится экшен, его ловит редьюсер, а редьюсер по сути своей не меняет старый стор...а создает новый объект и копирует в него информацию из старого...получается мы заменяем кусок стора полностью... Выглядит это так case CREATE_CATEGORY_SUCCESS: let newList = state.list; newList.unshift(action.data); return { ...state, list: newList, lastUpdated: + new Date()};

Романом, во всем с Вами согласен )). Да вариант хороший со сбросом стейта, я так никогда не делал, я просто стейтлес компоненты делаю, соответственно мне не приходится сбрасывать стейты, так как стейтов вообще нет :-D. Николай, думаю если Вы углубитесь, возможно измените свое мнение в отношении Редакса. Все, что Вы привели можно делать и с редаксом и компоненты можно монтировать к узлам стора точечьно и имутабл объекты хранить и все что угодно :-). Если стор сделать имутабельным проблем с производительностью не будет, ну и конечно же в компонентах использующих жизненный цикл использовать SCU не просто не страшно, а очень даже нужно, если у Вас компонент содержит внутренние стейты :-). Николай, посмотрите про машину времени ))). Мотаем туда сюда, мутируем стор в ретроспективу, сохраняем состояние стора, импонт / экспорт, фиксация стора. Redux Dev Tools, посмотрите, шикарная штука, особенно когда дебаг нужен. Зафиксировал стор, обновляешь страницу, а все в нужном состоянии )).