две похожие сущности, но разного типа, с немного отличающимися полями и лежащие в одной таблице в базе (хранение в одной таблице обусловлено бизнес логикой)?
Например:
* Есть таблица articles, в которой есть столбец с типом статьи
* В зависимости от типа для статьи нужен конкретный набор полей из таблицы
* Возникает разумное желание разделить Object и Input типы на типы для разных типов статей, что в свою очередь ведет к потребности сделать Union для отображения статей разного типа в одном пагинируемом списке на фронте
Если в таком кейсе использование Union неправильно, то где это более применимо?
в вашем примере c articles лучше подойдет интерфейс
Я так понимаю, юнион больше для совсем разных сущностей - например для организации API для поиска по разным сущностям?
Возник вопрос об использовании типов, реализующих интерфейсы, на фронтенде. Ситуация следующая: * на фронте React и Apollo Client * настроена кодогенерация через graphql-codegen Судя по информации отсюда (https://www.apollographql.com/docs/react/v2/data/fragments/#fragments-on-unions-and-interfaces), клиент легко может запрашивать массив объектов, типы которых реализуют один и тот же интерфейс. При этом есть возможность настройки fragmentMatcher'а (https://www.graphql-code-generator.com/docs/plugins/fragment-matcher). Но вот вопрос - насколько удобно будет в коде видеть тип объекта? И как можно будет понять, какого типа объект? Будет ли у объектов, полученных в результате выполнения запроса, соответствующий сгенерированный Typescript тип?
Получается, что на фронте будет что-то такое? function Articles({ articles }: Articles) { return articles.map(article => { switch(article.__typename) { case "ArticleFirstType": return <ArticleFirst article={article} /> case "ArticleSecondType": return <ArticleSecond article={article} /> } }); }
Обсуждают сегодня