Я понял в чем баг был! У нас на эту ссылку 2 эвента повешено: от реакта и от роутера. Как сделать, чтобы от реакта эвент всегда дергался первым и прерывал все остальные?)))

от роутера же только если в <Link /> оборачиваешь

Все, уже разобрался)) Тут у нас говнороутер используется

https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

главная фича npm run eject

а какая маза делать два конфига вебпака?

Where are you

Мультисборка?

а какая маза делать два конфига вебпака?

для дева и прода различий много

для дева и прода различий много

Например

Например

минификация, хот релоадинг, прочие плагины

https://github.com/facebookincubator/create-react-app быстро они растут по звёздам :)

ого, это за пару часов )

yeomana видимо не хватает))

А кто-нибудь успел понять что это? Чем от yeoman отличается?

yeoman не нужен

лучше бы запилили что то на подобие этого

https://github.com/luqin/react-component-tools

А кто-нибудь успел понять что это? Чем от yeoman отличается?

Это чтобы еще больше todo листов наклепать

А кто-нибудь успел понять что это? Чем от yeoman отличается?

бойлерплейт без конфигурации)

yeomana видимо не хватает))

девелоперы надеются, что появится один нормальный бойлерплейт вместо тучи велосипедов из йомена

Да давно надо сделать было им это

Но до эмбера пока не дотягивает

минификация, хот релоадинг, прочие плагины

хот релоадинг в продакшине зачем?

хот релоадинг в продакшине зачем?

пффф..))

вот именно, что не за чем )

а минификация не очень много времени занимает

"dev": "NODE_ENV=development webpack-dev-server --inline --hot --progress", "build": "NODE_ENV=production webpack -p --progress", "server": "NODE_ENV=production babel-node server.babel.js",

все работает с одним конфигом

в чем вопрос-то?

о привет

Внутри вебпак же

Развод :)

Check out this devRant: https://www.devrant.io/rants/118522

ребят, подскажите, что за алгоритм шифрования может быть? 5eqtd4 <- 327096616 слева результат, справа исходник из результата можно получить только один исходник, так что это не хэш

в моем случае все решилось с помощью http://www.unitconversion.org/numbers/base-10-to-base-36-conversion.html

в моем случае все решилось с помощью http://www.unitconversion.org/numbers/base-10-to-base-36-conversion.html

:)

Привет! Поиграл в последнее время с Redux и возникли вопросы. Именно по поводу парадигмы, не технические. Может кто-то грамотно объяснить?

Все ниже - паста из другой конфы. Не вижу смысла еще раз писать

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

И не понял зачем оно :/

Не понимаю реальных плюсов от этого хоть каких-то. Код получается сваленным в кучу, в бесконечные свитчи reduser'a. А пусть я могу разделить их по файлам - суть сильно не меняется.

То, что есть всегда все данные приложения под рукой - по сути да, но по факту - нет. Что если речь идет о сложных приложениях, с хотябы десятками тысяч данных в БД?

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

Плюс все запросы нужно выполнять в Action Creators, и в случае успеха засовывать их в dispatcher

Что тоже довольно странная логика, ведь если я уже совершил запрос и ответ успешный, то зачем мне еще какая-то функция непонятным образом обратаывающая данные для того чтобы внести в локальный массив

При том, что REST должен мне отдавать и так весь созданый объект назад

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

ИМХО тот же подход с rxjs, когда у тебя есть синглтон сервисы шарящие Observable - круче, хотя все плюсы редукса имеет. Где-то запросил что-то через сервис - данные зафигачились на сервер (или запросились с сервера), и разослались всем через Observable

Связанность всех частей приложения с единым экземпляром данных и только одно место модификации - остаются. Но зато никаких проблем с кашей в одной части кода, и непоняток с тем как дергать сеть - нет.

Привет! Поиграл в последнее время с Redux и возникли вопросы. Именно по поводу парадигмы, не технические. Может кто-то грамотно объяснить?

запрос на сервер это получение какой-то dto, как ее преобразовать в модель еще надо знать, для этого и есть reducer. Простой кейс добавления товара в корзину: при клике добавить надо чтобы кнопка у этого товара в каталоге стала чем-то типа "добавлено" + в корзине добавилось, бекенд же на это тебе особо ничего не скажет(добавлено и инфу про товар), кнопки надо все еще обновлять. Вот все кнопки и корзина связаны с моделью(состояние в сторе), которая меняется единственным правильным атомарным способом

данные можешь в action-creator дергать, можешь с redux-saga, можешь свой middleware написать

redux действительно решает только одну задачу - эффективно хранить и менеджить стейт, используя односторонний data flow. Его цель как раз - избежать observables и обеспечить единообразный механизм обновления состояния приложения.

То-есть redux ставит задачу хранения данных только для отрисовки

Верно?

Решает задачу "

*

не совсем верно, но типа того:)

ERROR: S client not available

А как тогда работает например пагинация с ним? Можно пример?

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

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

выгружай тогда частями)

ну, мол, эта часть не изменилась кмк

Ну совсем понимаю как должен вести себя стэк редукса

То-есть там будет массив, в котором только подгруженные данные

есть вот тут https://github.com/reactjs/redux/tree/master/examples/real-world

Спасибо, сейчас гляну

но вообще в целом //actioncreator const fetchData(pageNum) = dispatch=> fetch('mydata', {pageNum}).then(data=>dispatch({type: 'DATA_RECEIVED', payload: {data, pageNum}})) //reducer switch(action.type){ case 'DATA_RECEIVED': return {...state, lastPageNum: action.payload.pageNum, data: state.data.concat(action.payload.data)} } // view onClick= fetchData(store.lastPageNum+1)

это в двух словах, и сильно срезая углы:)

Примерно понял

Спасибо

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

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

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

Да и вообще это плохая идея, грузить лишние данные, которые не нужны клиенту

Лишняя нагрузка

посмотри тогда еще в сторону graphql

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

Сервер может их отдавать по кусочкам асинхронно. А насчёт “не нужны”, это от приложения сильно зависит. Если можно делать поиск не обращаясь к серверу - это уже хорошо.

+

https://skladchik.com/threads/egghead-Доступ-к-обучающим-видео-на-1-месяц.114927/

Ну да. Я понимаю что это возможно, но я же написал что в конкретном случае о котором я говорю - нет. Данные слишком комплексные, и цена их формирования слишком дорога для бекэнда если учесть кол-во одновременных запросов от разных пользователей

Ну да. Я понимаю что это возможно, но я же написал что в конкретном случае о котором я говорю - нет. Данные слишком комплексные, и цена их формирования слишком дорога для бекэнда если учесть кол-во одновременных запросов от разных пользователей

Подобные данные очень хорошо кэшируются.

Ну к чему этот спор? :) Я спросил про конкретную ситуацию в фронтэнд фрэймворке, указал примерные исходные условия бэкэнда. Мне не важно что может flux, если затолкать в него все мои данные, потому что с моей точки зрения для данного проекта это невозможно. Не имеет значения почему - реально ли это невозможно, либо я недостаточно грамотный чтобы сделать правильный бэкэнд, сути не меняет

в общем redux вполне нормально себя чуствует, если ему дозагружать данные но есть и другие решения, которые основываются на этом)

Ну а если серьезно, то в нашей базе сейчас более 5 миллионов объектов, которые разнесены связями по 20 таблицам. Почти по каждой таблице есть сортировка и прочее. Мы даже count не можем считать по этой базе, сервер ляжет. Вместо него отдельная таблица, где инкрементируется число объектов

Так что о том чтобы загрузить все это на клиент речи идти не может

странно это

какая у вас субд?