FetchOrderFromDB

Одна функция

Делаем вторую WithLogger

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

почему их простосто не слать пропсом

зачем изворот?

FetchOrderAndWriteLog = WithLogger(FetchOrderFromDB)

а

ну в твоем примере это ясно и оправдано

Изменить поведение компонента без изменения кода компонента

но там

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

Нет, просто когда нужна модификация

При этом и оригинальное поведение тоже нужно сохранить

Например оно юзаетсч в другом месте

У абрама есть статьи на эту тему

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

о

а можно ссылочку пож

Mixins Are Dead. Long Live Composition – Dan Abramov – Medium https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750

Ну вот еще примеры hoc

Pure из recompose

Автоматом делает scu

Или еще пример

Есть компонент шахматная фигура которая принимает пропсом цвет

Делаешь два hoc'a белая фигура и черная фигура, оба врапят компонент шахматной фигуры

Но статично прописывают цвет

ну по сути исход и смысл один и тот же ж

вопрос в общем то в том при каких обстоятельствах действительно нужно вместо пропов юзать hoc

когда написание + нескольких строчек оправдано

Посмотри recompose

окей

я почитаю статью, посмотрю, надеюсь вопросы отпадут)

спс))

Когда какую-то логику нужно активно реиспользовать

WrapWithLoader на асинхронные компоненты

Логика: показывать спиннер на время загрузки данных

С возможностью применить для любого компонента

И тому подобное

понял, спасибо)

Ребята, перехожу с redux-thunk на redux-saga Разбираюсь и возникает вопрос, стоит ли юзать в саге заместь генераторов async/await, и не навредит ли оно?

Боже тебя упаси

Зачем тебе сага

Зачем тебе сага

+

объясните чем крута сага

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

Слез с нее на redux logic

Можно еще redux-observable

объясните чем крута сага

Никто не знает.

redux logic как то cb hell напоминает

хотя это на первый взгляд

В первом take latest, debounce и много плюшек из коробки

как то дофига кода, не находите?

Ща реальный код покажу

всем привет.Вы не расскажите куда можно вакансию разместить?)

В первом take latest, debounce и много плюшек из коробки

Также как и в saga.

в саге куча бойлерплейта

изкоробки

это все что в ней есть полезного

«полезного"

всем привет.Вы не расскажите куда можно вакансию разместить?)

@javascript_jobs

https://gist.github.com/DenisNeustroev/bd1d776a2cbf4e6ded5a5c38759186a3

@javascript_jobs

спасибо)

как саги динамически инжектить?

никак

ERROR: S client not available

только ручками

https://gist.github.com/DenisNeustroev/bd1d776a2cbf4e6ded5a5c38759186a3

а где ахиос?

в лоджик есть + автоматический диспач

{ client }

в обьекте инициализации лоджика прокидваешь нужные зависимости

в том числе и axios

в моем случае это apollo

а зачем reducer импортить?

О_о

import { fetchOrder, fetchOrderSuccess, fetchOrderFail, setStatus, setStatusSuccess, setStatusFail, } from './reducer

там экшоны

На проекте юзаем redux-saga, т.к. для больших проектов сага лучше вроде чем thunk

а в чем плюс то?

плюс чего?

плюс чего?

а понял у тебя в редусере лежат экшены

а в чем плюс то?

Плюс наверное в различных плюшках, которых в thunk нет.

это и константа и экшон в одном

дуализм?

да заебала мня сага

ее тестировать как с ежом ебаться

)

он и в асинк умеет

async process() и погнал

а для вывода ошибок в консоль

Удобно ??

Читаю сейчас статью, говорят наоборот удобно

ее тестировать как с ежом ебаться

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