feat: enhance favorites and playlists filtering logic

[KazeKaze93]

• Introduced shouldIncludePostInFavoritesQueue and shouldIncludePostInPlaylistQueue functions to filter posts based on various criteria including AI tags, ratings, media types, orientations, and date ranges.
• Updated the Favorites and PlaylistsPage components to utilize the new filtering functions when loading more posts, ensuring only relevant posts are appended to the viewer queue.
• Added context handling in PostCard and ViewerDialog components to conditionally render UI elements based on the current context (playlist or not).
• Cleaned up unused imports and ensured adherence to strict coding standards throughout the changes.

[github-actions]

🛡️ Архитектор (AI Review)

Это Code Review. Пристегнись, архитектура местами пахнет легаси и костылями.

🚨 Критично

1. Бизнес-логика в Renderer (Performance & Architecture):
   Ты добавил shouldIncludePostInFavoritesQueue и shouldIncludePostInPlaylistQueue прямо в компоненты. Это фильтрация на стороне клиента.

   • Проблема: Ты запрашиваешь данные из SQLite через IPC, гоняешь сериализованные JSON-объекты через мост, а потом просто выкидываешь их в рендерере. Если фильтр отсеет 90% постов, пользователю придется ждать лишние циклы подгрузки.
   • Решение: Перенеси эту логику в Main-процесс, в слой Drizzle ORM. Используй .where(and(...)) в запросах. База данных фильтрует быстрее, чем твой JS-поток.

2. Дублирование логики (DRY Violation):
   Функции shouldIncludePostInFavoritesQueue и shouldIncludePostInPlaylistQueue практически идентичны. Копипаста — первый шаг к багам синхронизации.

   • Решение: Вынеси общую логику фильтрации в src/shared/utils/filters.ts или аналогичный хелпер.

⚠️ Надо исправить

1. Магический костыль с ID:

   .map((post) => (post.id === 0 && post.postId ? post.postId : post.id));

   Что это за id === 0? Если у тебя в базе есть записи с ID 0, у тебя проблемы со схемой. Если это "виртуальные" посты, то логика выбора между id и postId должна быть инкапсулирована в модели данных или Drizzle-трансформере, а не размазана по UI-слою.

2. A11y (Доступность):
   В PostCard.tsx ты используешь span с role="button".

   <span role="button" tabIndex={0} ... >

   Зачем? У тебя есть Button из UI-кита или обычный <button>. Использование span заставляет тебя вручную обрабатывать onKeyDown (Enter/Space), что ты и сделал, но это лишний код и потенциальные ошибки фокуса.

3. Zustand & Side Effects:
   В PlaylistsPage.tsx:

   void fetchNextPage().then((result) => { ... appendQueueIds(filteredIds); });

   Вызов appendQueueIds внутри .then после fetchNextPage — это грязный хак. Если компонент размонтируется до завершения промиса, ты получишь попытку обновления стейта на "мертвом" компоненте (хотя Zustand это проглатывает, логически это мусор). Используй useEffect для реакции на изменение данных из react-query.

💡 Совет

1. Оптимизация фильтрации:
   В shouldIncludePostInFavoritesQueue ты делаешь post.rating.trim().toLowerCase().charAt(0). Если в очереди 1000 элементов, ты будешь делать это на каждой итерации фильтра.

   • Совет: Нормализуй данные при записи в БД или при получении из неё. В рендерер должны приходить уже готовые константы 's' | 'q' | 'e'.

2. Типизация фильтров:
   Вместо передачи объекта фильтров в функцию, опиши интерфейс PostFilters и используй его везде. Сейчас у тебя в Favorites.tsx и PlaylistsPage.tsx типы фильтров объявлены локально и слегка отличаются.

3. React Key:

   key={post.id > 0 ? post.id : post.postId}

   Это "запах кода". Если id может быть невалидным, создай стабильный uid на уровне маппинга данных из БД.

---

Итог: Код рабочий, но архитектурно слабый. Ты перегружаешь Renderer логикой, которая должна жить в Main/DB слое. Исправь дублирование и убери фильтрацию из UI-компонентов. 🟢 (Условно пропущено, но с серьезными замечаниями).

Analyzed by: gemini-3-flash-preview