%
ну так себе утверждение, если честно
Ну а в чем разница?
Size: a a a
2020 April 07
KB
Ну а в чем разница?
Представим есть 20 эндпоинтов, которые возвращают данные, которые успешно должны быть расшарины на весь проект. Так же данные имеют сложную структуру вложенностей. Так же для усложнения нужно делать например некий запрос только после ответа с определённого ендпоинта с использованием данных из ответа первого.
если взять редакс, то все вызовы выносятса в саги, или эпики, или санки, где легко сделать второй запрос автоматом после первого,
для вытаскивания данных из нужного слоя вложенности юзаем селекторы,
был опыт тестирования чат бота на реакте, так там саги выполняли по 3-4 запроса последовательно, и была очень нехилое разветвление логики
Теперь я пытаюсь представить как это сделать на контексте и редьюсере, и как-то сложно выходит.
Я конечно могу очень сильно ошибаться, но для каждого кейса своё решение, если это простая апка, с простым набором данных, с минимум апиколов, то пожалуйста, если это что-то большое и сложное, как чат бот, то логика общения с апишкой должна быть в абстрактном слое отдельно от view представления, т.е. в редаксе.
если взять редакс, то все вызовы выносятса в саги, или эпики, или санки, где легко сделать второй запрос автоматом после первого,
для вытаскивания данных из нужного слоя вложенности юзаем селекторы,
был опыт тестирования чат бота на реакте, так там саги выполняли по 3-4 запроса последовательно, и была очень нехилое разветвление логики
Теперь я пытаюсь представить как это сделать на контексте и редьюсере, и как-то сложно выходит.
Я конечно могу очень сильно ошибаться, но для каждого кейса своё решение, если это простая апка, с простым набором данных, с минимум апиколов, то пожалуйста, если это что-то большое и сложное, как чат бот, то логика общения с апишкой должна быть в абстрактном слое отдельно от view представления, т.е. в редаксе.
KB
ну и для RN и redux есть persist либа, которая поможет избежать потери данных при закрытии приложения, и не нужно городить свой огород для сейва данных в асинксторедж
KB
логика общения с апишкой должна быть в абстрактном слое отдельно от view представления, т.е. в редаксе.
* не именно в редаксе, а в приконекченных эпиках.сагах.санках к редаксу
* не именно в редаксе, а в приконекченных эпиках.сагах.санках к редаксу
DT
redux полностью заменяется через контекст и useReducer, при этом как правило нет необходимости содержать дорогой глобальный стэйт и обслуживать его на каждый чих
> нет необходимости содержать дорогой глобальный стэйт и обслуживать его на каждый чих
Как раз таки контекст и провайдеры нужно держать в реакт мемо что выходит в мусор в реакт дереве
Как раз таки контекст и провайдеры нужно держать в реакт мемо что выходит в мусор в реакт дереве
DT
Либо все через чилдрены передавать
%
Представим есть 20 эндпоинтов, которые возвращают данные, которые успешно должны быть расшарины на весь проект. Так же данные имеют сложную структуру вложенностей. Так же для усложнения нужно делать например некий запрос только после ответа с определённого ендпоинта с использованием данных из ответа первого.
если взять редакс, то все вызовы выносятса в саги, или эпики, или санки, где легко сделать второй запрос автоматом после первого,
для вытаскивания данных из нужного слоя вложенности юзаем селекторы,
был опыт тестирования чат бота на реакте, так там саги выполняли по 3-4 запроса последовательно, и была очень нехилое разветвление логики
Теперь я пытаюсь представить как это сделать на контексте и редьюсере, и как-то сложно выходит.
Я конечно могу очень сильно ошибаться, но для каждого кейса своё решение, если это простая апка, с простым набором данных, с минимум апиколов, то пожалуйста, если это что-то большое и сложное, как чат бот, то логика общения с апишкой должна быть в абстрактном слое отдельно от view представления, т.е. в редаксе.
если взять редакс, то все вызовы выносятса в саги, или эпики, или санки, где легко сделать второй запрос автоматом после первого,
для вытаскивания данных из нужного слоя вложенности юзаем селекторы,
был опыт тестирования чат бота на реакте, так там саги выполняли по 3-4 запроса последовательно, и была очень нехилое разветвление логики
Теперь я пытаюсь представить как это сделать на контексте и редьюсере, и как-то сложно выходит.
Я конечно могу очень сильно ошибаться, но для каждого кейса своё решение, если это простая апка, с простым набором данных, с минимум апиколов, то пожалуйста, если это что-то большое и сложное, как чат бот, то логика общения с апишкой должна быть в абстрактном слое отдельно от view представления, т.е. в редаксе.
Ну тут все проще совсем чуток, что дает нам redux? Он дает нам стор и persist (который по сути сериализует данные в AsyncStorage) и dispatch. Больше нам от него ничего не надо. Reducers мы пишем сами, саги пишем сами и actions вызываем сами, то есть редакс нам нужен только до тех пор, пока мы не обновились до контекста. У редакса опять же есть эклсистема дебаггеров, это жирный плюс, однако с практической точки зрения, ребята тз реакта сделали все инструменты для того, чтобы отказаться от внешних зависимостей. Что дергать в саге - не важно, и там и там есть dispatch, редьюсеры - useReducer отлично работает.
Однако есть такая штука, как привычка и знакомые нам инструменты, зарекомендовавшие себя со временем, трудно исключить из работы. Тут ничего не поделаешь.
По поводу большого стэйта - всем рекомендую разбить его на много мелких, увы поддержка и валидация состояния на клиенте и синхронизация его с бэкендом это больно и дорого
Однако есть такая штука, как привычка и знакомые нам инструменты, зарекомендовавшие себя со временем, трудно исключить из работы. Тут ничего не поделаешь.
По поводу большого стэйта - всем рекомендую разбить его на много мелких, увы поддержка и валидация состояния на клиенте и синхронизация его с бэкендом это больно и дорого
DT
И возможно тогда будет часть голого редакса
%
> нет необходимости содержать дорогой глобальный стэйт и обслуживать его на каждый чих
Как раз таки контекст и провайдеры нужно держать в реакт мемо что выходит в мусор в реакт дереве
Как раз таки контекст и провайдеры нужно держать в реакт мемо что выходит в мусор в реакт дереве
Мусор в реакт дереве не выглядит такой большой проблемой, как, например, сторадж в 100кб в одном финансовом приложении, которое мне довелост посмотреть. Эти 100кб гонялись по сети туда сюда для валидации хранилища, при том что клиент был на мальте на 3G в роуминге.
DT
Мусор в реакт дереве не выглядит такой большой проблемой, как, например, сторадж в 100кб в одном финансовом приложении, которое мне довелост посмотреть. Эти 100кб гонялись по сети туда сюда для валидации хранилища, при том что клиент был на мальте на 3G в роуминге.
Проблема не в инструменте. А в подходах к работе. Если есть отторжение к редаксу, то можно посмотреть в сторону реатом или эффектора
KB
Проблема не в инструменте. плюсую
KB
ну парни, просветите меня, как используя контекст содержать в нём данные из 20 эндпоинтов? и где делать запросы?
%
Вопрос в другом - в каждом ли месте вам нужен доступ ко всему состоянию? Вы же все равно селекторы пишете для доступа к определенной его части
%
А потом эти селекторы переиспользуете в разных компонентах для доступа к данным
AN
тут скорее вопрос что делать если рано или поздно он, доступ этот, понадобится)
%
Самолет может полетит, а может не полетит
%
Если понадобится, то ради одного кейса данные можно собрать в одну кучу используя useContext
AN
да понятно что можно. можно и зайца курить научить как говорится. вопрос сколько велосипедов будет написано и кто это все потом будет поддерживать)
%
Так, я тут набросил, могу как-нибудь рассказать как это работает в большом приложении с кучей распределенных данных (беттинг и форекс) а сейчас всем пиво, господа 🍺
