санки с ожиданием экшинов

но опять же, это ничем не лучше саговского варианта ибо нифига не очевидно

ожидание по type экшена это пиздецок

ожидание по type экшена это пиздецок

есть такое дело, согласен

но это уже вопрос организации кода и его документирования

вот сам не в восторге от того, что есть код, который ждет экшин где-то там и надо держать это в голове

с другой стороны, все решения на observable этим страдают

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

есть такое дело, согласен

если по делу, у нас был проект на сагах, и там ребята из-за вынужденности понаписали такого сложного процесса сага сагой погоняет сага ожидает сагу (втф?!) и подобного много чтобы это переписать, мне пришлось изучить всю логику тупо не читая код саг, ибо это не очевидно и не понятно (“зачем там ждать экшен? почему здесь диспатчися экшен? ааа, чтобы вооон та сага сработала…”) но переписав на санки, я полностью избавился от ожидания экшена, вместо этого появились нормальные стейты процессов, которые можно дебажить и логгировать. В некоторых случаях кода стало больше (на 5-10 строк), от неочевидности не везде получилось избавиться (бизнес-логика она такая видимо), но в общем, разработка стала проще. Может я не вкурил в саги, но я пытался, искренне, ибо концепция дико понравилась, даже имплементировал свой вариант, чтобы разобраться как оно работает. Но когда понял, выкинул идею подружиться с сагами, ибо где-то там постоянно крутящиеся саги мне оч не понравилось

с другой стороны, все решения на observable этим страдают

поэтому предпочитаю обычное решение на future/promise + синхронщина

ну я очень хорошо понимаю о чем ты говоришь

так как очень много саг написал

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

есть в этом и плюсы и минусы

поэтому предпочитаю обычное решение на future/promise + синхронщина

плюсов есть несколько: - поймет практичекски любой знакомый с es6 - нет магии под капотом - простой синтаксис - написать тесты может почти любой чувак - код по большей части очевиден (dispatch — почти равносилен прозрачному вызову функции)

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

тут еще есть разница что у тебя в проекте используется REST API или ws/event source

у меня была дичайшая помесь всего этого

где запросы уходят по ресту порой, ответы возвращаются через ws/es

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

ну тут я тоже согласен. я вижу у саг одно преимущество для категорически сложного сценария они подходят лучше, ибо код будет более очевиден. ну это тоже не всегда так

и там без саг был бы адок

и там без саг был бы адок

возможно; пока что удалось работать только с помесью rest и ws причем и для rest и для ws имелись fallback api с двух сторон

ну у меня рест запрос, тут же моментанльно ответ, что запрос принят успешно и потом я жду через ws реальную дату уже

возможно; пока что удалось работать только с помесью rest и ws причем и для rest и для ws имелись fallback api с двух сторон

ну для ws 2 события: some-request, some-answer

ну для ws 2 события: some-request, some-answer

ну как тебе сказать :)) у меня request, success, failure, timeout, retry, cancel, nodata

ну для ws 2 события: some-request, some-answer

поэтому request(‘some’), сначала пытался(или нет) делать rest, в случае невозможности делал ws some-request и ждал пока придет some-answer, или же обваливался по таймауту

было больно

ну как тебе сказать :)) у меня request, success, failure, timeout, retry, cancel, nodata

воу) не у нас проще, ибо все пихалось в один ответ (кроме cancel, retry) это уже транспорт делал

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

делал такое, поищу код

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

Эпики

Эпики

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

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

У стримов нет механизма для движения данных в обратную сторону) push only как правило

У стримов нет механизма для движения данных в обратную сторону) push only как правило

Он и не нужен

Знаешь что бывает с механизмами без обратной связи?)

Знаешь что бывает с механизмами без обратной связи?)

Отсутствие механизма "движения данных в обратную сторону" не означает отсутствие обратной связи.

Подскажите кто работал с material ui в чем трабла с stiky для appbar

Может нужен какой watcher

Подскажите кто работал с material ui в чем трабла с stiky для appbar

какая версия mui?

Подскажите кто работал с material ui в чем трабла с stiky для appbar

я работал, в чем вопрос то?

я работал, в чем вопрос то?

Ну вопрос собственно в том, что AppBar со свойством stiky таки не ползает

Ну вопрос собственно в том, что AppBar со свойством stiky таки не ползает

ты какую версию таки юзаешь?

ты какую версию таки юзаешь?

"material-ui": "^1.0.0-beta.45"

"material-ui": "^1.0.0-beta.45"

понятно :)

по этой версии не подскажу, у меня крайняя 0.20 во всех проектах на материале

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

я всегда так делал когда сталкивался с косяками в этой либе

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

Привет, eslint уже умеет все то, что умеет prettier? или по прежнему в eslint конфиге живет prettier правило у вас?

eslint и раньше форматировать умел.

eslint и раньше форматировать умел.

умел, но преттир зачем-то вышел и набрал “классы”. Какова была причина популярности?

ERROR: S client not available

Ненастраиваемость, а следовательно, отсутствие холиваров в команде.

Ненастраиваемость, а следовательно, отсутствие холиваров в команде.

хм, у него же есть конфиг, или что имеется в виду под “ненастраиваемостью” ?

хм, у него же есть конфиг, или что имеется в виду под “ненастраиваемостью” ?

Там только самые холиварные настройки типа "пробелы vs табы".

Там только самые холиварные настройки типа "пробелы vs табы".

ок. спасибо

Всем привет, может кто подсказать в чем может быть проблема ? http://prntscr.com/jfltl1

http://prntscr.com/jflu7h

умел, но преттир зачем-то вышел и набрал “классы”. Какова была причина популярности?

То что у еслинта это не профильная задача и он регулярно откровенно тупит

обман чтобы набрать классы

Всем привет, может кто подсказать в чем может быть проблема ? http://prntscr.com/jfltl1

Там же написано. Для output нужен обсолютный путь. И то что свойство ‘loaders’ неизвестно, т.к. такого нет, но есть rules

Первая страница документации https://webpack.js.org/concepts/#loaders

То что у еслинта это не профильная задача и он регулярно откровенно тупит

Такой ответ мне больше нравится.

Ненастраиваемость, а следовательно, отсутствие холиваров в команде.

Не только

Для меня это главное.

Он форматирует ещё намного больше, чем еслинт

Еслинт разве что пробелы втыкает и че там ещё он делает

С преттиером можно написать код в одну строку через хуй и он все форматнет

С преттиером можно написать код в одну строку через хуй и он все форматнет

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

Нет, не умеет

ребят, а как бы мне заюзать этот синтаксис фрагментов? <>...</>

чет ошибку выдает

или пока что нельзя?

babel плагин

если create-react-app, то «из коробки» нет

если create-react-app, то «из коробки» нет

ага, понял. А какой именно плагин?