http://webpack.github.io/analyse/ И проанализировать например такой тулзой

Попробовал --profile, но данных недостаточно) А webpack-bundle-size-analyzer(полезная штука, кстати) не умеет в такое. @maullerz А в analyse надо просто json закинуть? Сейчас попробую

ага, stat json который генерит вебпак с соответствующим ключом

обычно больше всего сорсмэпы жрут

и uglify

webpack —profile —json > stats.json

uglify вообще на DO 1гб vps кладет на небольшом проекте запросто)

собственно это из мануала http://webpack.github.io/docs/build-performance.html

крутой сервис. Даже не потребовал загружать все 16 метров json'а)

что получилось? статы моего проекта он кушать не хочет)

Да, данные показывает, но это просто размеры из бандла. Для этой цели использовал https://github.com/robertknight/webpack-bundle-size-analyzer Хочется как-то замерить какие именно пакеты долго думают, когда хотрелоад происходит)

https://github.com/dimaip/server-side-rendering

Вдруг кому-то пригодится

> Да, данные показывает, но это просто размеры из бандла. должно показывать и время на билд модулей

http://stackoverflow.com/questions/32923085/how-to-optimize-webpacks-build-time-using-prefetchplugin-analyse-tool

http://webpack.github.io/analyse/#hints здесь показывается время билда модулей

кто нибудь использова happypack https://github.com/amireh/happypack ? каие мысли о нем? сейчас имеется проблема с временем сборки, думаю, что еще можно сделать

Свежий выпуск RadioJS №39: React, мед, пиво и все остальное — https://radiojs.ru/2016/05/radiojs-39/

посоны

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

он, грубо говоря, просто фетчит json

на клиенте я могу прописать fetch('/file.json') и всё будет ок

независимо от домена

а на сервере как быть?

как-то можно к локалхосту обратиться или что-то такое?

а что за сервер то у тебя?

express

ну так в ноде просто require('./file.json') вроде канает

http://stackoverflow.com/questions/7163061/is-there-a-require-for-json-in-node-js

Может тебе нужно что-то вроде этого? https://github.com/matthew-andrews/isomorphic-fetch

у меня он и используется

но проблема именно в пути к файлу

json лежит на другом сервере/домене?

на этом сервере

но домен может быть разный ведь

т. е. локально один домен, на продакшене другой

а какая разница? у тебя физически скрипт, в котором нужен этот json и сам json находятся на одной машине? или могут быть на разных?

на одной машине

если это у тебя какой то статичный json, который вместе с сервером, грубо говоря, гуляет, то и запрашивай его просто через require

зачем тебе что-то изобретать, на сервере обращаться к самому себе, чтобы он тебе файл отдавал

у меня был объект API который просто 2 раза был реализован

1 на клиенте, 2 на сервере

1 ходил к API через fetch, второй к методам модели.

но сейчас бы я не стал так делать. Проще сделать отдельно сервер API, отдельно сервер рендера

ага, спасибо. так и сделаю пока что

если это у тебя какой то статичный json, который вместе с сервером, грубо говоря, гуляет, то и запрашивай его просто через require

зачем тебе что-то изобретать, на сервере обращаться к самому себе, чтобы он тебе файл отдавал

:)

а ещё по редаксу такой вопрос

есть у меня экшн, например, CHANGE_PAGE

когда он диспатчится, мне нужно автоматически задиспатчить асинхронный экшн, загружащий данные

как это правильно реализовать?

store.subscribe()?

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

мне кажется в мидлвейре логичне такие вещи делать

Неа Тот элемент, которому нужны эти данные, должен слушать стор, который реагирует на CHANGE_PAGE

С другой стороны, change_page судя по названию страницу меняет, а значит меняет отображаемые элементы, в том числе тот, которому нужны данные. Потому самое логичное и ожидаемое то, что при смене страницы у тебя отобразится новый элемент-контейнер, который инициализирует запрос в componentWillMount()

не

у меня есть список

с пагинацией

при смене страницы просто меняются данные в списке

и эти данные подгружаются с сервера

Ясно

ERROR: S client not available

тогда так —

Неа Тот элемент, которому нужны эти данные, должен слушать стор, который реагирует на CHANGE_PAGE

то есть в componentDidMount подписаться на обновления стора?

как обычно :)

Если это по редаксу, то почему не @connect?

а чем @connect поможет?

он за стором следит

то есть в componentDidMount подписаться на обновления стора?

вместо этого

https://github.com/JonathanUsername/nplaym

но сейчас бы я не стал так делать. Проще сделать отдельно сервер API, отдельно сервер рендера

Кстати, господа, вот я давно хожу с мыслью, что надо два отдельных сервера: UI (рендера) и отдельно API (ну и еще пара вспомогательных для запуска фоновых процессов). Так вот вопрос, кто еще такой подход использует и как вы это все скрещиваете?

https://github.com/JonathanUsername/nplaym

Внедряем!

когда он диспатчится, мне нужно автоматически задиспатчить асинхронный экшн, загружащий данные

Посмотри на redux-saga

или redux-thunk - он проще и универсальнее

у меня redux-thunk используется

а чем @connect поможет?

а чем не поможет-то?)

ну я уже понял)

Кстати, господа, вот я давно хожу с мыслью, что надо два отдельных сервера: UI (рендера) и отдельно API (ну и еще пара вспомогательных для запуска фоновых процессов). Так вот вопрос, кто еще такой подход использует и как вы это все скрещиваете?

Я про это в докладах осенью и говорил. Мы клиентам делаем с микросервисной архитектурой. Пример сейчас проект - за nginx на разных роутах: + Корневой роут - Front-end Server (HTML Renderer) + Отдельный роут - микро-сервис на Golang, OSS решение для обработки и отдачи изображений + Отдельный роут - микро-сервис на C++, OSS решение для обработки данных + Отдельный роут - микро-сервис на Node.js для агрегации данных, оркестрации и балансировки внешних сервисов

Слайд 46: http://www.slideshare.net/denisizmaylov/isomorphic-react-applications-performance-and-scalability

Я про это в докладах осенью и говорил. Мы клиентам делаем с микросервисной архитектурой. Пример сейчас проект - за nginx на разных роутах: + Корневой роут - Front-end Server (HTML Renderer) + Отдельный роут - микро-сервис на Golang, OSS решение для обработки и отдачи изображений + Отдельный роут - микро-сервис на C++, OSS решение для обработки данных + Отдельный роут - микро-сервис на Node.js для агрегации данных, оркестрации и балансировки внешних сервисов

Спасибо за информацию. Слайды гляну попозже. А на счет два последних пункта: Обработка данных, в смысле с работа с пользовательским вводом, сохранение, удаление и т.п.? Сервис агрегации как раз API для доступа к данным?

Слайд 46: http://www.slideshare.net/denisizmaylov/isomorphic-react-applications-performance-and-scalability

Ага, посмотрел. Я по-моему уже его видел. Пока не отвечает на вопрос как скрестить данные. Отдельная подготовка на стороне сервера отдельной логикой или через тот же API, который используется для работы с состоянием (redux etc) в приложении на клиенте.

One micro-service reponds only for one thing

GraphQL для таких случаев как раз, как средство агрегации данных

из разных источников

Я той же мысли придерживаюсь.

GraphQL надо пробовать. Мне идея очень нравится, но пока не до конца понимаю как ее на стороне сервера использовать для получения данных.

Надо разбираться.

Кстати, Денис, ты меня заинтриговал, что за штука у вас такая на Go для обработки и генерации картинок?

На Go есть много сервисов :) Конкретно для этого проекта необходимо было проксирование изображений, сделал через https://github.com/willnorris/imageproxy

Спасибо Докеру :) мы можем использовать, что угодно

звучит не совсем точно, за c++ и node.js могут жить обычные жирные монолитные приложухи

Я про это в докладах осенью и говорил. Мы клиентам делаем с микросервисной архитектурой. Пример сейчас проект - за nginx на разных роутах: + Корневой роут - Front-end Server (HTML Renderer) + Отдельный роут - микро-сервис на Golang, OSS решение для обработки и отдачи изображений + Отдельный роут - микро-сервис на C++, OSS решение для обработки данных + Отдельный роут - микро-сервис на Node.js для агрегации данных, оркестрации и балансировки внешних сервисов