Я описал выше вариант "тесты после кода", когда интересно увидеть только общую картину. Но когда TDD, и тесты нужны на каждый чих, то в сагах детализация глубже.
SSR использую в полный рост, только не понял, к чему этот уточняющий вопрос — assignAll не работает на сервере?
Я отказался совсем от биндинга экшенов, не использую mapDispatchToProps, наоборот предпочитаю явно дергать dispatch(), но в результате боевой код имеет много лишнего:
По моим наблюдениям и личному опыту, рынок труда в сфере ИТ во время текущего кризиса все больше похож на бизнес-отношения в строительстве. (Там давно уже за правило попробовать кинуть подрядчика, перед тем, как заплатить).
И вас (и меня) еще не раз ожидают подобные ситуации.
Открываю правила Хабра (может быть что-то изменилось — нет):
Если у вас проблемы с сотовым оператором, с провайдером интернета или хостинга, или с чем-то ещё, всегда можно связаться со службой поддержки нужного вам ресурса. Или с компетентными органами. Но не следует использовать «Хабр» как рупор, дабы рассказать всем о постигшей вас ситуации.
Очевидно, вы пролистали на мою заметку по диагонали, Apollo упоминается два раза. Но суть уловили верно. Задача развязать клиент и сервер в рамках существующего долгоиграющего проекта (без Apollo). И Redux мне в этом поможет.
Например. Сравнивая CRA и CRA-TS, меня смущает, что tsconfig.json и tslint.json торчат наружу. Да, я хотел бы иметь возможность их править при необходимости, но мне нужны "настройки по умолчанию". Это крайне ценное назначение CRA, на мой вкус.
В этом весь цимес, обновление CRA хоть каждый день, без последствий за пару минут! И никакой магии, вставьте console.log(config) в config-overrides.js — конфиг webpack, как на ладони.
Я пришёл к такому разделению редюсеров. Есть общий редюсер app, где свалка глобальных состояний приложения. Для каждой сущности два редюсера: item и list. При этом редюсер для item используется на нескольких страницах (просмотр и редактирование сущности). При этом данные отображаемых сущностей в списке (list) спрятаны в локальных стейтах, а в редюсерах живут флаги и сайд-эффекты. И только данные для item так же живут в редюсере, потому что их нужно отображать в форме и в превью (например). Благодаря redux-act, ни один switch не пострадал.
Я описал выше вариант "тесты после кода", когда интересно увидеть только общую картину. Но когда TDD, и тесты нужны на каждый чих, то в сагах детализация глубже.
SSR использую в полный рост, только не понял, к чему этот уточняющий вопрос — assignAll не работает на сервере?
Я отказался совсем от биндинга экшенов, не использую mapDispatchToProps, наоборот предпочитаю явно дергать dispatch(), но в результате боевой код имеет много лишнего:
Спасибо, записал в блокнотик "подумать, как спрятать dispatch". Только оно должно работать с redux-thunk и redux-saga.
Про фашизм у Фридмана — это для максимального контраста?
"Компьютер — это конечный автомат". Алан Кокс, прим. Википедия
Блин, раньше считал, что сам это придумал.
Ага, тысячи их. У меня был дармовой доступ к самой большой коллекции в Питере.
В свое время я пытался освоить все игры для ZX Spectrum — тоже было непросто. А вот для 3DO задача оказалась выполнима, но полгода выпало из жизни.
Реквестирую перевод Simple Made Easy
По моим наблюдениям и личному опыту, рынок труда в сфере ИТ во время текущего кризиса все больше похож на бизнес-отношения в строительстве. (Там давно уже за правило попробовать кинуть подрядчика, перед тем, как заплатить).
И вас (и меня) еще не раз ожидают подобные ситуации.
Открываю правила Хабра (может быть что-то изменилось — нет):
Это была одна из ключевых причин перехода с WebStorm на VSCode. Но мне для TypeScript, меняйте специализацию на React Native. :)
Реквестирую сравнение с конкурентами.
Нашёл способ кастомизировать: 10 шагов настройки Create React App + TypeScript + Ant-Design.
Очевидно, вы пролистали на мою заметку по диагонали, Apollo упоминается два раза. Но суть уловили верно. Задача развязать клиент и сервер в рамках существующего долгоиграющего проекта (без Apollo). И Redux мне в этом поможет.
Я неточно выразился. Представляю себе Redux, как архитектуру движения данных в приложении. Так лучше?
Например. Сравнивая CRA и CRA-TS, меня смущает, что tsconfig.json и tslint.json торчат наружу. Да, я хотел бы иметь возможность их править при необходимости, но мне нужны "настройки по умолчанию". Это крайне ценное назначение CRA, на мой вкус.
Не понял. У вас же по коду прибавилось функционала (подключение к реакт-роутеру).
Затык случился лишь однажды, когда CRA переехал на Webpack 2 — тынц.
В этом весь цимес, обновление CRA хоть каждый день, без последствий за пару минут! И никакой магии, вставьте console.log(config) в config-overrides.js — конфиг webpack, как на ладони.
Вот и всё, что мне нужно для щастья:
yarn add --dev file:path/to/your/custom/package
Я пришёл к такому разделению редюсеров. Есть общий редюсер app, где свалка глобальных состояний приложения. Для каждой сущности два редюсера: item и list. При этом редюсер для item используется на нескольких страницах (просмотр и редактирование сущности). При этом данные отображаемых сущностей в списке (list) спрятаны в локальных стейтах, а в редюсерах живут флаги и сайд-эффекты. И только данные для item так же живут в редюсере, потому что их нужно отображать в форме и в превью (например). Благодаря redux-act, ни один switch не пострадал.