2+ часа потрачены впустую... Судя по всему просто возникли коллизии в dist, так как Resource.ts был перемещен в Resource/index.ts, а dist не очищалась перед билдом. В итоге в ней были и Resource.ts и Resource/index.ts

Вот это был подводный камень... При плановой оценке в часик, было потрачено более 6 часов с усердными изысканиями. Задача стояла в формировании выборки средних рейтингов по компаниями и типам оценок. Призма хоть и умеет уже в группировку, но весьма ограничено и с сортировкой в таких случаях все очень плохо. Вот такой запрос был на призме: Но проблема в первую очередь в том, что сортировка в призме в groupBy возможна только по полям, указанным в by (то есть по которым группируется), но не по значениям avg и т.п. (а надо-то именно по ним, чтобы от больших оценок к меньшим отсортировать). Вторая проблема в том, что к такой конструкции призма не позволяет добавить select(), то есть выборку дополнительных полей. В моем случае надо было сразу получить и данные компаний, чтобы не делать потом кучу запросов на получение данных компаний для каждого результата в отдельности. Сначала быстро накидал чистый SQL-запрос, но там нет типизации нифига, то есть результат просто как any. А хотелось, чтобы с проверкой типов и т.п. В итоге подключил knex. Тот тоже уже немного в ТС умеет, но все же во многом путается. Пришлось конструировать 3-хуровневую конструкцию, чтобы с типами было боле менее ОК. Конечно не идеально, но в целом весьма удовлетворительно получилось. Вот такой запрос получился: https://github.com/gorodskie-bani-ru/nextjs/blob/078e051afeafc76e19c804a88ba3da284972952e/server/nexus/types/Query/definitions/society/Vote/index.ts#L80-L195 На выходе вот такой SQL: Кстати, вот здесь можно поиграться с knex: https://dgadelha.github.io/knex-playground/

Только в этом топике по существу скорее всего не будет ничего написано. Надо смотреть конечные задачи. Их там две, но они объемные и обсуждения много. Особенно полезна первая задача и видосик в ней..

Довольно интересный получился эксперимент и в целом результат положительный, но не обошлось без шероховаточтей. Во-первых, генератор типов graphql-code-generator офигел от фрагментов с юнионами и наплодил неиспользуемых дубликатов, из-за чего пришлось добавить в шаблон // @ts-nocheck, чтобы typescript не ругался на неиспользуемые переменные. Вот здесь обсуждение: https://github.com/dotansimha/graphql-code-generator/issues/4008 Во-вторых, аполло-клиент так же троит с юнионами и просит указывать possibleTypes, чтобы мемори-кеш понимал такие фрагменты. Указал. В остальном вроде все ОК и положительный эффект имеется. Теперь не только исбавился от необходимости указывать условие для выборки документов по parent или template (вместо этого получил два отдельных запроса reviews и topics), но и получилось создать отдельный фрагмент topic, и указать его тип в карточке топика, чтобы во вьюху можно было передавать данные именно этих типов ресурсов, но не другие (как то Компания, Город или просто Resource).

Супер! Главное, что данные не ухнули в лету)

Вообще тут используется @fullcalendar/core (который сам по себе совсем не реактовый), обернутый в @fullcalendar/react, в котором явно есть баги с ивентами (я тоже натыкался пару раз не неправильное поведение). Так что если что, просто обнови страницу для надежности.

Убрал длинные задачи - пропали данные за 03.03 и календаря, в таймере всё ок. Я вот сейчас не понял, где-то что-то пошло не так?

Убрал длинные задачи - пропали данные за 03.03 и календаря, в таймере всё ок.