Я работаю над разработкой Redux-приложения, особенно моего объекта State.
Я собираюсь использовать API POST, подобный этому:
/api/posts
с методом POST.
Если бы я выполнял правила, которые я использовал в прошлом, у меня получилось бы свойство posts и свойство activePost для моего глобального объекта состояния.
Свойство posts, которое предположительно было бы создано их редукторами постов, вероятно, будет массивом, и оно будет содержать список всех разных сообщений, которые у меня есть внутри приложения.
Я хочу сохранить список сообщений внутри объекта, а не массив, и полностью исключить необходимость в activePost. Таким образом, это будет выглядеть так:
{
4: {title: 'Hello', id: 4, content: 'Hi', tags: 'greetings'},
12: {title: 'Bye', id: 12, content: 'Bye', tags: 'greetings'},
}
Обратите внимание, что внутри этого объекта я говорю, что ключ - это идентификатор сообщения, а значение - это сама запись. Таким образом, объект начинается с числа 4 и закрывается в конце фигурной скобки. Он имеет идентификатор 4 и использует ключ из 4, потому что его идентификатор сообщения. То же самое для следующего ниже.
Причиной этого является упрощение поиска определенного сообщения из всех сообщений, которые я получаю.
Может ли это работать даже с большими наборами сообщений? Будет ли это лучшей практикой? Почему или почему нет? Если это не соответствует какой-либо цели, просьба указать документированную причину. Спасибо.
Я считаю, что это лучшая практика, по сути, очень продвинутая концепция. Я слышал, как коллеги говорят, что массив работает лучше всего для больших наборов данных, но не так много документации для резервного копирования своих заявок.
Для этого, вероятно, потребуется очень сложный рефакторинг с чем-то вроде:
state.posts[postId]
и это вернет данный пост, postId, исходящий из идентификационного номера с URL-адреса, а затем используя это число, чтобы посмотреть на объект множества разных сообщений.
Я понимаю, что так оно и делается в производстве и с большими приложениями, которые хорошо масштабируются, поэтому на самом деле они будут работать с большими данными.