All streams
Search
Write a publication
Pull to refresh
-1
0

User

Send message
Materialize в зипе — 63кб, распакованный — 315кб, из которых 174кб жаваскрипта
а для чего переписывать урл к картинкам? если картинка уже есть у пользователя, все равно вернется 304. Чаще всего браузер вообще не пойдет в сеть и покажет картинку из кеша, не проверяя есть ли изменения
Failed to compile.
Failed to minify the code from this file: 
        ./node_modules/proxy-polyfill/src/proxy.js:18 

в прошлый раз вроде таких проблем не было, на дев-билде тестировать — не понятно, вроде стало так же как и без либы

ws идет поверх http, для балансировки нужно будет как-то сообщать клиенту в какой порт стучаться, но да, всё реализуемо

Ну всего лимит 65к коннектов с одного клиента в один порт, минус занятые файловые дескрипторы, можно и с одного клиента 1кк коннектов открыть, если в разные порты и лимиты настроить, но про разные порты я не подумал, а с лимитами в lxc было что-то мутно. Кстати как балансировать 20 разных портов?

спасибо за статью, всегда интересно читать про использование вебсокетов =) я тоже как-то давно развлекался поднятием 1кк коннектов на домашнем компе, выдерживало 800к, сообщения ходили, все было ок, старенький amd на 4 ядра и 16гб оперативы, java. Тестировать это было интересно, пришлось поднять 20 виртуалок по 40к коннектов
найс, я оказывается вхожу в топ 0,15%, но с поиском работы это никак не помогло, кажется только один раз хедхантер заинтересовался, что у меня коммиты на гитхаб каждый день

спасибо, уберу ...ownProps, будет чуть быстрее… я еще посмотрел, mapStateToProps дергаются примерно 8000 раз на рендере страницы

с ownProps не заморачивался, есть — есть, нет — пустой объект будет, что сильно не мешает.
есть вариант, когда из стейта более конкретные данные вытягиваются


const mapStateToProps = (state, ownProps) => {
  return ({
    ...ownProps,
    item: state.tasks[ownProps.id]
  });
};

вот наверно самый жирный


const mapStateToProps = (state, ownProps) => {
    return {
        ...ownProps,
        tasks: state.tasks,
        news: state.news.data,
        announcements: state.announcements.data,
        loading: (!!state.tasks.loading || !state.tasks.data) || (!!state.announcements.loading || !state.announcements.data) || (!!state.news.loading || !state.news.data)
    }
};
дашборд с кучей карточек, 425 реквестов к бекенду, 1043 экшена прокидывается через редакс, 84 компонента, слушающие стейт
попробовал более магическую магию (beautiful-react-redux), время отрисовки страницы поднялось с 2.0 секунд до 2.7. Не все так радужно как кажется
componentWillReceiveProps может дергаться без изменения данных, так что туда класть что-либо тяжелое не очень прикольно
так я и говорю что не нужно ничего вычислять, просто переложить данные из стейта в пропс, а вычислять потом в рендере, да, он тяжелый, но он по дизайну тяжелый, и он не будет дергаться если ничего не изменилось
mapStateToProps и так вызовется у каждого компонента на каждый экшен, если ничего не изменилось и результат вызова mapStateToProps такой же, то редакс не будет дергать реакт, что нам и нужно. Но чем больше логики мы кладем в mapStateToProps тем медленнее наше приложение, да, можно использвать кеши, но их вызовы и проверки тоже не бесплатные

Так рендер не вызовется, пока данные не изменятся

Сорри, я всё ещё не понимаю, зачем все эти движения, отдельные библиотеки, почему бы просто не считать ничего в mapStateToProps, передать сырые данные, а потом в том же рендере сделать с ними все что нужно?

выглядит очень интересно, а последовательную загрузку с учетом приоритетов файлов оно умеет?
python рекомендуется многими как первый язык программирования, т.к. порог входа довольно низкий
легко, https://nodejs.org/
-> скачиваете lts версию
-> распаковываете
->
export NODE_HOME=<путь до ноды>
export PATH=$PATH:$NODE_HOME/bin
->…
-> profit!

Information

Rating
Does not participate
Registered
Activity