#reactjs #typescript #react-redux #state #reducers
#reactjs #typescript #реагирование-сокращение #состояние #редукторы
Вопрос:
Redux (с помощью typescript) новичок здесь!
Исходя из серверной разработки (java), использование typescript является обязательным из-за проверки типов, но использование typescript для создания общего состояния является для нас проблемой, потому что было написано много шаблонного кода и много ошибок проверки типов, но на самом деле это не вопрос, просто контекст.
В настоящее время перед нами стояла задача создать приложение react с typescript использованием rest API, которое не контролируется нашей командой. Этот API очень стандартный и нормализован таким образом, что объект никогда не приводит в ответ связанные объекты (дочерние), поэтому не расширяется. Чтобы получить дочерний элемент, необходимо выполнить второй вызов API. Пока все шло хорошо, но это создало нам проблему при реализации формы состояния redux.
Когда началась реализация нашего приложения, мы отказались от использования byId/allIds формы для каждого фрагмента состояния объекта. Это было хорошее решение, потому что оно очень помогло при использовании useSelector . Но, как я уже говорил ранее, rest API в нашем случае не извлекает расширенные дочерние элементы, поэтому обработка всех byId/allIds отношений между связанными объектами стала проблемой для поддержания.
Например, давайте используем типичную модель посткомментария, чтобы выразить нашу проблему. Представьте себе дерево состояний, подобное этому:
{
posts : {
byId : {
"p1" : {
id : "p1",
comments : ["c1", "c2"]
},
},
allIds : ["p1"]
},
comments : {
byId : {
"c1" : {
id : "c1",
},
"c2" : {
id : "c2",
},
},
allIds : ["c1", "c2"]
}
}
Очевидно, что если это состояние одинаково reducer , легко распространять данные связи post-comments, потому что доступно все состояние. Но что произойдет, если сообщения и комментарии будут иметь свои собственные reducer ? Это не проблема, если API post предоставляет идентификаторы комментариев, но в нашем случае это невозможно. В нашем случае, чтобы получить комментарии, относящиеся к сообщению, должен быть выполнен второй вызов API ( getCommentsByPost ), а затем распространен другим редуктором.
Чтобы решить эту проблему, мы решили разделить действия (например FETCH_COMMENTS_BY_POST ) между редукторами связанных объектов. Это работает, но как только я узнал больше redux , я был удивлен, что сокращение композиции тоже является опцией.
Если бы у нас был отказ от сокращения композиции, корневой редуктор сообщений / комментариев обрабатывает общее действие, и это также решает проблему.
Мой вопрос: в масштабируемом приложении (модель все еще растет), каков наилучший вариант для этого? общие действия или уменьшить композицию для связанных объектов?