Уж так повелось. Мы используем данный подход и он нам очень нравится. И все счастливы. И мы каждый день танцуем и пьём ромашковый чай.
А если серьёзно — все 3 используются для того, чтобы приложение вело себя абсолютно предсказуемо. Мне не надо детально читать код моих коллег если они пишут так же, как написал бы я. Использование общих паттернов сильно упрощает жизнь на проекте.
Опять же мы не в тёплом мире Python, где есть только один способ сделать работу правильно. У всех свои вкусы. Нам нравится подход с RFS.
Напишите API функции и её результат, т.к. явные преимущество данного подхода мне не совсем ясно.
Есть 2 причины того, что первым аргументом идёт не адрес в вэбе, а функция с промисом:
Я использую axios, параллельном проекте ребята используют fetch, кто-то может вообще вставить туда setTimeout (и не наша забота судить его).
Иногда нужно сделать больше одного запроса параллельно, а сохранять их надо в одном месте. Пример: юзверь у нас собирается путём запросов (отдельно) базовых данных, данных о компании, данных о доверенном лице… всего 6 запросов на разные эндпоинты. В таком случае аргумент from выглядит так: () => Promise.all([ запрос1, запрос2, ... запрос6 ]). Конечно, можно их описать и сгенерировать уже "под капотом", но данный подход показался нам более прагматичным и простым.
За экшеном стоит логика, и если она общая, то и реализовать её можно обобщённо
Такая мысля есть. На данный момент либа писалась исключительно под наш проект, а мы в обязательном порядке используем все 3 экшна. Мысля же состоит в том, чтобы параметр to мог иметь не все { request, failure, success }, а произвольое их число. Тогда выполним только те экшны, для которых указан путь созранения данных. Если фичу кто-то запросит (или сам сделает PR) — фича будет.
immutable не является объектом статьи, но раз уж пошел трэд — вот мои фифтисэнт.
Immutable действительно пишется дольше, чем {}, однако прелесть его состоит в разнообразии методов для обработки данных. Благодаря функциональной парадигме и продуманности API можно писать очень удобочитаемый код без привлечения сторонних библиотек. А ведь код читают намного чаще, чем пишут.
По поводу Вашей библиотеки — дайте посмотреть. С удовольствием почерпну качественных знаний, если таковые там есть (в чём не сомневаюсь).
Говоря о "экспортировать таймлайн в файл" — не пробовал, надо заняться.
О, никаких шагов в сторону от редакса сделано небыло. Более того, я и сам бы принялся порицать такие начинания. fromTo возвращает стандартную функцию от (dispatch, getState), которую redux-thunk разбивает на отдельные REQUEST/FAILURE/SUCCESS. Просто мы не прописываем экшны явно — они собираются из аргументов (from, to, through).
Спасибо за статью. У меня вопрос: термин "затягивание графа" был придуман Вами именно для этой статьи? Т.к. гугление данного термина такого понятия не показало, а термин стягивание графа — это не то, что Вы здесь используете (при стягивании цикла нельзя получить ничего кроме цикла пока количество вершин результирующего цикла больше двух).
Если же термин "затягивание графа" существует — пожалуйста дайте указание "где посмотреть".
Спасибо, с удовольствием прочёл статью, очень познавательно.
Вы не могли бы добавить пример с внутренней структурой
indicesиentriesв словаре, в который добавили 2 элемента с одинаковыми хешами?Уж так повелось. Мы используем данный подход и он нам очень нравится. И все счастливы. И мы каждый день танцуем и пьём ромашковый чай.
А если серьёзно — все 3 используются для того, чтобы приложение вело себя абсолютно предсказуемо. Мне не надо детально читать код моих коллег если они пишут так же, как написал бы я. Использование общих паттернов сильно упрощает жизнь на проекте.
Опять же мы не в тёплом мире Python, где есть только один способ сделать работу правильно. У всех свои вкусы. Нам нравится подход с RFS.
Напишите API функции и её результат, т.к. явные преимущество данного подхода мне не совсем ясно.
Есть 2 причины того, что первым аргументом идёт не адрес в вэбе, а функция с промисом:
fromвыглядит так:() => Promise.all([ запрос1, запрос2, ... запрос6 ]). Конечно, можно их описать и сгенерировать уже "под капотом", но данный подход показался нам более прагматичным и простым.Собственно, этим библиотека и занимается.
В данный момент в случае удачного запроса диспатчатся 2 экшна:
{ type: '@@redux-from-to/some/path/REQUEST', requestTarget, errorTarget }{ type: '@@redux-from-to/some/path/SUCCESS', requestTarget, dataTarget, data }В предложенном Вами варианте экшнов тоже будет 2:
{ type: 'FETCH_ЧТО_НИБУДЬ', target, status: 'pending' }{ type: 'FETCH_ЧТО_НИБУДЬ', target, status: 'success', data }Плюс варианта в этой библиотеки в том, что я могу сохранять данные о RFS куда хочу и как хочу (что часто для нас является критичным).
В чём выгода Вашего варианта?
Такая мысля есть. На данный момент либа писалась исключительно под наш проект, а мы в обязательном порядке используем все 3 экшна. Мысля же состоит в том, чтобы параметр
toмог иметь не все{ request, failure, success }, а произвольое их число. Тогда выполним только те экшны, для которых указан путь созранения данных. Если фичу кто-то запросит (или сам сделает PR) — фича будет.immutableне является объектом статьи, но раз уж пошел трэд — вот мои фифтисэнт.Immutableдействительно пишется дольше, чем{}, однако прелесть его состоит в разнообразии методов для обработки данных. Благодаря функциональной парадигме и продуманности API можно писать очень удобочитаемый код без привлечения сторонних библиотек. А ведь код читают намного чаще, чем пишут.По поводу Вашей библиотеки — дайте посмотреть. С удовольствием почерпну качественных знаний, если таковые там есть (в чём не сомневаюсь).
Говоря о "экспортировать таймлайн в файл" — не пробовал, надо заняться.
О, никаких шагов в сторону от редакса сделано небыло. Более того, я и сам бы принялся порицать такие начинания.
fromToвозвращает стандартную функцию от(dispatch, getState), которуюredux-thunkразбивает на отдельные REQUEST/FAILURE/SUCCESS. Просто мы не прописываем экшны явно — они собираются из аргументов(from, to, through).А вот к копипасте у меня откровенная нелюбовь.
Соглашусь с комментарием swandir'а. Не совсем понимаю причину, по которой это является антипаттерном. Можно увидеть аргументацию?
Спасибо за статью. У меня вопрос: термин "затягивание графа" был придуман Вами именно для этой статьи? Т.к. гугление данного термина такого понятия не показало, а термин стягивание графа — это не то, что Вы здесь используете (при стягивании цикла нельзя получить ничего кроме цикла пока количество вершин результирующего цикла больше двух).
Если же термин "затягивание графа" существует — пожалуйста дайте указание "где посмотреть".