Как правильно организовать загрузку данных в React?
Привет, подскажите пожалуйста пару деталей, для более ясного представления приведу пример. Один из самых популярных примеров приложения на React это Todo-app. Представим вот этот самый Todo-app, и добавим сюда простенькую регистрацию/авторизацию и хранение заметок на сервере в базе данных.
Я вижу два варианта получения данных, но не понимаю какой правильный(или оба правильные?):
1. На чистом React. В самом компоненте, при помощи componentDidMount или useEffect отправлять запрос через fetch или axios, а ответ записывать в state. А на основании state отображать или лоадер, или массив компонентов-"заметок".
2. Добавить redux, react-redux и какой-нибудь middleware. Создать store, объявить там isLoading, isLoaded, data, isError. Написать ещё 4 action generator: fecth, request, response, error, и обрабатывать запрос как сайд-эффект в redux-saga или fetch в redux-thunk. А на страничке отображать лоадер на основании store.getState() или props с connect()().
Так вот, как правильнее то? Или оба подхода правильны? Когда какой использовать? Или оба неправильны?
Оба правильные. Если приложение настоящее, то второй правильнее. Если это тудулист/мелкий петпроект, то первый вариант. Первый быстрее, второй масштабируется лучше.
Как понять масштабируется? Если я правильно понял, то если я решу добавить функциональности в Todo-app, вроде возможности редактирования прогресса заметок, или хранение полноценной информации пользователя, может какую-то систему переписок пользователей, то это всё писать по второму сценарию? Но разве это хороший подход, хранить так много информации в хранилище? Да и кроме прочего, это же огромное количество кода. В первом варианте всё можно написать в 1-2 файла, во втором начинаешь разворачиваться целую структуру, где будут папки или файлы constans/actions/reducers/store/saga. Неужели все так пишут?
Goshan41k, не редаксом единым. Есть reatom, effector, mobx — первые два переосмысливают редакс и позволяют писать меньше кода. Последний просто другой.
На редаксе да, так все пишут. Ибо когда у вас появится необходимость расширить код, то проще это сделать, когда логика приложения отделена от логики отображения.
Вот вы добавили все перечисленные фичи. Например, вам нужно показывать уведомление об успешном/неудачном ответе от сервера — в первом случае Вам придётся залезть в код каждого компонента, ответственного за сетевые соединения и изменить его. Во втором у вас будет одна middleware, которая отвечает за сетевые соединения. Потом вам понадобится в четырёх местах использовать данные о юзере — вы будете делать четыре сетевых запроса или просто четыре раза сходите в одно и то же хранилище одним и тем же селектором? Потом вам понадобится, например, выводить туду-элементы, группируя их по юзерам. Туду-элементы запрашиваются компонентом-списком, а юзеры — компонентом-карточкой с юзерами. Продолжать можно бесконечно. Редакс позволяет управлять такой сложностью и не погрязнуть в хитросплетениях компонентов. Логика отдельно, а вьюхи отдельно.
Кроме того, есть redux-toolkit (в доке к редаксу найдёте) — он позволяет писать ГОРАЗДО меньше кода.
А как понять когда state нужно делить?
Я если честно, уже путаться начинаю. Вроде как три варианта действия.
1. До redux'a вполне себе удобно прокидывать через props что-то, и вот тебе одинаковые данные в нескольких компонентах.
2. С редаксом.
3. Сейчас ещё и через хуки + контекст можно прокидывать стейт.
Что можно почитать, чтобы лучше понимать архитектуру приложений?
Goshan41k, не всегда удобно кидаться пропсами через несколько компонентов.
Нет правильной и неправильной архитектуры. Пропсы, контекст и редакс — это все инструменты реакта. Просто зачем вам тащить редакс в компонент, который сам может прекрасно загрузить данные по апи и пробросить их пропсами дальше. Приложение-то совсем простое. Вот если у вас будет множество точек соприкосновения и вверх и вниз, тогда несите редакс.
abberati, если честно, понятней не стало, в комментариях дали достойную контр-аргументацию в пользу контекста. А автор ниже призывает вовсе отказаться от локального стейта, что мне кажется странным и непонятным.
Goshan41k, к моменту, когда ваше решение на хуках с контекстом станет удобным и масштабируемым, вы сами уже напишете свой редакс (на хуках и контексте, да)
только оригинальный редакс оттестирован, а в сети есть тысячи статей про редакс – люди говорят на одном языке одинаковыми терминами. когда вы попытаетесь решить проблему в своём велосипеде, вам понадобится гораздо больше сил и времени.
впрочем – вы вправе решать сами, я подсказываю путь, на котором вы набьёте меньше шишек. я не призываю отказываться от локального скейта, это на самом деле странно. но общий посыл у заметки верный: хотите разобраться "как что работает", хотите набить шишек – пишите велосипед на хуках-контексте или без контекста. хотите написать проект за деньги – берите опробованную архитектуру, в которой вам придётся придумывать меньше всего. набивать шишки полезно. но лучше не делать это за чужие деньги
abberati, спасибо, кажется я понял. Сейчас попробую выжать максимум функциональности из своего Todo-app, и на практике закрепить понимание удобности редакса. И отдельное спасибо за redux-toolkit, я пока только мельком глянул документацию, но уже сильно заинтригован.
Средний