Осталось Nexus ввести и можно углубляться в детали каждой технологии. Будь готов к тому, что вот в этот момент у тебя весь твой маленький мир и порушится :) Маленький мир здесь - это твой проект. Я пока не буду тебе детали раскрывать, сначала поломай голову сам. Интересно, во что именно ты упрешься.

Николай, привет! Спасибо, проштудирую. Я сейчас Apollo Server настроил и через Apollo Client получаю данные (ветка plusapollo), как раз стоит вопрос о переписке фильтра. Осталось Nexus ввести и можно углубляться в детали каждой технологии.

Хотел вынести в компонент и пропсами пробрасывать состояние выбранной категории. Но не свел все вместе с getServerSideProps(). Так а ты документацию официальную читал? https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering getServerSideProps имеет аргумент - context. А из этого контексты ты можешь получить множество полезных данных, включая GET-параметры и т.п. Разве это тебе не помогает в твоем вопросе?

Николай, привет! >>> >> Пока искал решение задачи - понял её абсурдность: зачем делать запросы с условиями, если все данные на руках и можно фильровать их на месте. 1. Представь себе вытянуть многие сотни тысяч записей на клиент сразу. 2. Фильтрацию и сортировку сразу по нескольким полям (особенно при выборке сразу из нескольких таблиц) ты замахаешься делать на клиенте. Доволно простые для SQL задачи окажутся практически невозможными в реализации. --- Это понятно, но для конкретного проекта - подходящее решение. Вопрос: Я сначала хотел запихать условие в Через свойство where. И как динамически это сделать на одной странице не разобрался. Была идея сделать пять страниц со своими параметрами. Хотел вынести в компонент и пропсами пробрасывать состояние выбранной категории. Но не свел все вместе с getServerSideProps(). Можешь подсказать, как было бы сделать правильно?

Дима, привет! Вижу, что уже знаешь больше и можешь что-то сделать. Это хорошо. Но есть моменты, конечно. >> Пока искал решение задачи - понял её абсурдность: зачем делать запросы с условиями, если все данные на руках и можно фильровать их на месте. 1. Представь себе вытянуть многие сотни тысяч записей на клиент сразу. 2. Фильтрацию и сортировку сразу по нескольким полям (особенно при выборке сразу из нескольких таблиц) ты замахаешься делать на клиенте. Доволно простые для SQL задачи окажутся практически невозможными в реализации. >> Выяснилось, что единственное правилое для них место - папка public, дальше вложенность не имеет значения. Все верно. По соображениям безопасности JS не отдает просто так любой файл как статику. Вдруг у тебя там когфиг с паролями? Поэтому в next-js настроена отдача статики из public. Но можно и свои кастомные папки сервить. К примеру, вот здесь у меня мидлвара ресайза картинок, а так же сервинг из папок shared/ и uploads/ https://github.com/prisma-cms/nextjs-nexus/blob/43e101b9804245bd551aefbf8e067cfd808c1d0d/server/index.ts#L26-L42

А он есть) и коммит с добавлением есть. Тогда добавлю ссыль. Единственное, как фиксировать разные моменты проекта надо понять

Дима, привет! Рад, что ты что-то для себя новое освоил:) Но все же еще надо над знаниями поработать. И очень важно: поработать над терминами. Пока что ты многое называешь совсем не своими именами. Примеры. >> Табличка простая, подвешенная в воздухе, без связей. И надо эту новую табличку запихать в БД: Нет, это еще не табличка. Пока что это только схема, описывающая структуру таблицы. Вот когда ты yarn prisma:push выполнишь, вот тогда призма возьмет эту схему, прочитает, сопоставит с текущей базой данных и сгенерирует запросы для обновления этой базы данных так, что бы она соответствовала схеме. Плюс к этому, призма сгенерирует все необходимые методы и типы, чтобы можно было работать с базой данных средствами JS. Все, больше никаких функций эта схема не выполняет и напрямую к БД никак не относится. >> //Расширяем объект Query, добавляя новое свойство tech Посмотри внимательно, у тебя там не только tech добавляется, но и techs Ну а в целом, было бы сильно полезней, если бы ты сделал под эту статью сам клон проекта, все на нем выполнил, что в статье описываешь, и потом вылил бы измененный проект на гитхаб и сослался бы уже на измененный код, а не на исходный. И каждый желающий мог бы себе склонировать проект, запустить, перепроверить информацию. Да, так дольше, но так сильно эффективней. Я так делаю обычно.

Тоже верно. Ну значит аполло буду ковырять уже на призма-цмс))

Пойми: есть задачи по настройке системы, а есть задачи по программированию. Все эти настройки отнимают очень много времени, а выхлопа дают очень мало. Вместо того, чтобы заниматься этим, ты мог бы, к примеру, SQL поучить. Все пользы было бы больше. SQL действительно важен. А настройка этих компонентов отдельных: высокоуровневым специалистом ты вряд ли станешь (даже я не тяну в этом направлении на такой уровень). И получается, что денег ты с этого не заработаешь (никто не станет платить нормальные деньги за работу низкого качества). При этом ты потеряешь в навыках того, что действительно должен знать и за что должны платить. Если ты хочешь понять как призма работает, разбирай уже существующую систему (бери ломай и следи за тем, где что поменялось), но не пытайся этого выстроить с нуля самостоятельно. Самая коварная штука в том, что не зная как это должно работать, ты не сможешь нормально выстроить с нуля, и получется так, что даже если ты что-то сможешь сделать, вероятнее всего это будет не оптимально и не правильно. И ты попадешь в ловушку своих же знаний: будешь думать что понял, а на самом деле все совсем не так.

Разумно. А я понимаю, что скорее всего это резюме буду на prisma-cms делать) Правда качество работы с системой после этих моих изысканий должно улучшиться. Колупая призму я наконец-то понял, что это такое и зачем нужна. Осталось на аполло выстроить api и можно смело разворачивать prisma-cms))) Может и не совсем зряшное дело делаю. С любом случае спасибо!