Отслеживание сообщений, которые понравились пользователю - флаттер и пожарный

Question

Справочная информация:

Я пытаюсь создать приложение, в котором пользователь может прокручивать посты и нажимать «нравится» на некоторых из них. Я использую FireStore для бэкэнда, и все это приложение для флаттера.

Вопрос:

Я хочу иметь возможность отслеживать сообщения, которые понравились пользователю, поэтому, если сообщение появляется снова, у меня может быть индикатор «Мне нравится» уже включен. Это будет связано с обращением к бэкэнду, чтобы проверить, понравился ли пост или нет. Тем не менее, я не хочу звонить на сервер для каждого сообщения, чтобы проверить, понравилось ли пользователю это или нет, так как пользователь не видел / не любил подавляющее большинство сообщений. В идеале я хотел бы сохранить локальный список сообщений, которые пользователь уже просмотрел или полюбил, поэтому я могу просто сравнить запись с локальным списком, а не звонить бэкэнду. Я не уверен, что лучший / самый эффективный и устойчивый способ сделать это.

Альтернативно:

Я бы хотел получить индикатор того, понравился ли пользователю сообщение в том же вызове, что и я, получая другое сообщение. Информация. Какая структура вызова / базы данных подойдет для этого?

Пример:

Если мне нравится публикация на Tumblr, а затем она снова встречается, то между Я вижу сообщение и индикатор «Мне нравится», например, нет момента, когда индикатор «Мне нравится» загружается из выключенного состояния в другое, он уже включен, когда я вижу сообщение. Это заставляет меня думать, что пост и его статус «как» загружаются одновременно. Это тот эффект, которого я пытаюсь достичь, и мне все равно, как, но Вопрос и Альтернатива были две идеи, которые у меня были об этом.

Если Кто-нибудь знает, как это сделать, пожалуйста, дайте мне знать!

Answer 1

Поскольку пост может быть достаточно большим сам по себе, а список пользователей, которым он понравился, может быть слишком длинным, я предлагаю придерживаться следующей структуры:

Каждый пост - это документ, который содержит карту со ссылкой на списки пользователей. Каждый из этих списков сам по себе является Документом. Таким образом, вы можете иметь столько пользователей, сколько хотите, чтобы понравиться каждому сообщению, и сохранять 1MB size limit каждого документа только для содержания сообщения.

В моем примере у меня есть все 3 документа в одной коллекции , но вы можете отделить списки пользователей от сообщений.

Образец почтового документа:

Пример документа со списком пользователей, которым понравилось сообщение:

Answer 2

Техника, которую я использовал для хранения пользовательских голосов (или лайков) в сообщении таким образом, чтобы не требовалось многократных или сложных запросов к базе данных на основе документов, такой как Firestore, заключалась в сохранении идентификаторов пользователей пользователей, которые имеют проголосовал в массиве в самом документе Post. Например:

Это позволяет сравнить идентификатор пользователя в приложении с идентификаторами списка в массиве userVote. Вы сразу узнаете, проголосовал ли этот пользователь за это сообщение.

Если вы хотите, чтобы решающий голос пользователя сразу отразился на вашем приложении и не стал ждать, пока результат базы данных отразится на вашем представлении, вы можете немедленно измените голосование локально в приложении, а затем получите результат нового снимка, который вы слушаете, чтобы обновить представление при его поступлении.