У тебя может быть не установлен нужный stage-*

Проект для деплоя собирается и запускается, но именно babel-node ругается на установленный бабель

Ошибки приходят не очевидные

Ну попробуй убрать бабелрц

Уже попробовал ради тебя- не помогло)

Крч, мне вчера это помогло. Нужный stage я прописывал в виде аргументов

У меня встречный есть вопрос, как правильно сделать погрузку данных, если пропсы в стейт не записывать

Зависит от архитектуры проекта

flux, redux, mobx

Redux

Ты должен изменять стор и его изменения передавать в компоненты

Еще раз, не совсем понял что значит изменять стор, стор это же стейт так?

http://redux.js.org/docs/introduction/

Ты должен изменять стор и его изменения передавать в компоненты

Я так и делаю, получаю данные в пропсы и вывожу результат. Вопрос вот в чем как сделать погрузку данных по кнопке не записывая пропсы в стейт

кнопка вызывает action

Да, кнопка вызывает екш, данные передаются в пропс

что значит "погрузка данных"?

Ну с сервера ты получил 1,2,3 нажимаешь на кнопку 'Еще' и получаешь следующие данные 4,5,6

Выше мне сказали что пропсы в стейт записывать - плохая практика

У меня встречный есть вопрос, как правильно сделать погрузку данных, если пропсы в стейт не записывать

Делай стейтлес компоненты, в пропсы везде прокинешь где надо и все

А как их вообще можно записывать в стейт?

А как их вообще можно записывать в стейт?

Как факт- можно Но нахера?

Как и любое другое значение

Пропсы в стейт - у них разный смысл ваще

Ну, в смысле, технически-то понятно, да.

Но как вы к этому пришли, коллега? =)

Делай стейтлес компоненты, в пропсы везде прокинешь где надо и все

Можно подробнее про это

Я вот сам не понимаю, он вроде бы говорит, что делает как надо, но почему в его вопросе стейт всплывает- я хз

Не держи данные в стейте компонента, весь стейт держи в сторе

Ну мне же нужно где-то хранить предыдущие данные

Ты к предыдущим данным пишешь новые

В сторе

Не держи данные в стейте компонента, весь стейт держи в сторе

А есть статейки почитать про это

А то- как их писать- твоя задача

Редакс интро

Я уже кидал ссылку

Ты к предыдущим данным пишешь новые

А старые данные хранить в сторе, а не в стейте

Прочти от и до все, что там написано, потом задавай вопросы

Если не знаешь английского- пардон, ма шер

Почему нальзя и поле $(input[type=file]).prop('files'); удалять файлы?

почему это поле read only ?

что за лажа вообще?

Почему нальзя и поле $(input[type=file]).prop('files'); удалять файлы?

Почитай доки, а потом посмотри github/mailru/FileAPI

Обезательно, обезательно прочту

только не на работе

Ахаха

если вкратце, почему нельзя удалять отуда элементы?

Не держи данные в стейте компонента, весь стейт держи в сторе

Скорей всего моя проблема, я в редьюсерах просто заменял данные, а их нужно добавлять. Т.е стор это и есть инишиалстейт в редьюсерах?

Лучше проложить в реакт чате

Разобрался. Работает

А есть ссылка?

@react_js

Спасибо

> Если уважаешь Неймара и Месси, нажми на кубок ??? и подпишись! ? ?

Лоол

у людей перегрузка инфы наоборот, имхо

Что быстрее двойной for или двойной reduce?

Тебя это волновать не должно

Настало время экономить на спичках

скоро пойдут ассемблерные вставки

Я сейчас оптимизирую по скорости модуль pipe / compose

Для ощущения разницы for / reduce приходится давать серьёзную нагрузку

а я картинки сжал

ERROR: S client not available

Что быстрее двойной for или двойной reduce?

Бенч @ отвечай

а я картинки сжал

Я не в плане того что проект ускоряю, я просто делаю самую быструю реализацию pipe / compose и поэтому зависаю в бенчах

Самая быстрая по сравнению с чем

Жкверийным?

Самая быстрая по сравнению с чем

Реализации в redux, Ramda и lodash уже обогнал

Очень круто на самом деле осознавать что смог обогнать лодаш))

И сколько минимум нужно данных чтобы увидеть разницу?

Compose длиной в типичный редакс стейт

Что быстрее двойной for или двойной reduce?

Lodash flatten для объектов есть?

Но я пока рассуждаю в op / sec, а человеческие выводы пока только в процессе

Пока расклад такой

При том, что у меня модуль принимает массивы функций любой вложенности

что-то мне кажется, что производительность может меняться, причём довольно значительно в зависимости от JS движка

Да

Три этапа — определиться с наиболее быстрым подходом, сформировать наиборее реалистичные бенчи, оптимизировать на различных движках

Вот я пока на втором этапе

поэтому я на самом деле не могу согласиться с таким вниманием к производительности, понятное дело, что производительность - это важно, но на мой взгляд о производительности нужно думать в последнюю очередь

а если уж и думать, то в правильном ключе

Ты о производительности не должен думать вообще

например делать упор на производительность в мобилках

так как на десктопах нужно постараться, чтобы сделать просадку производительности

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

так как на десктопах нужно постараться, чтобы сделать просадку производительности

Есть ещё задачи nodejs

Есть ещё задачи nodejs

Где слабыми местами обычно является дисковый и сетевой ввод-вывод.

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

опять же лучше сначала думать о хорошем интерфейсе модуля

Сильно от задач зависит всё это

Чаще не нужно оное, но вот когда нужно...

опять же лучше сначала думать о хорошем интерфейсе модуля

Я же написал, это первый этап

Сильно от задач зависит всё это

Кеп в студии Я хотел раньше написать это!