ну и соответственно тот самый кейс - запросили email, выдали вам null
как вам понять недоступен он или не заполнен? В массив errors писать можно об этом, но это неудобно (нет строгой типизации в ошибках, просто набор полей, перечисление типов ошибок). Получается что контракт по ошибкам хранится где-то в другом месте, а о сущностях - в схеме. Хочется чтобы было единое место знаний - схема.
NonNull (или восклицательный знак) означает не обязательность ответа, а то, Что если вы его запросили, оно точно не null. И избавляться от этих пометок это самое последнее что хочется делать. Клиенту хочется знать что всегда заполнено, а на что ему надо обрабатывать null-ы GraphQL на то он и нужен, что никакой обязательности ответов нет, запрашивай что хочешь (иначе смысл?)
Может не понял про список полей, но у кандидата будет поле contacts типа Contacts, как-то так:
union Contacts = ContactsItem | ContactsError
type ContactsItem {
items: Contact[]
}
type Contact {
type: ContactType #email,phone,...
value: String
}
type ContactsError {
errorType: ContactsErrorType
# тут тип, например "Неоплачен доступ", "Кандидат скрыл данные" и т.д
}
Да, могут быть разные блоки, еще например ФИО и день рождения, их можно целиком еще в один объект. Если прям хочется динамические блоки в зависимости от ролей, и динамически включать и выключать, то тут конечно придется уже наверное более синтетические списки этих самых полей в дженерном виде.
Пример достаточно топорный, там можно накручивать.. Могут быть полные и не полные контакты (будет три состояния, вообще недоступны, виден только часть, видны все). + со списками еще логика такая - выдаем то, что доступно тебе (когда запрашиваешь "мои вакансии", тут все как в обычном REST API)
Не очень понял с чего вывод про наверняка) И все таки, что значит "появляются всегда". Если речь о том, что есть место в приложении, где мы показываем маленькую часть объекта - так GraphQL и нужен для этого, клиент просит только эти поля.
В реальности у нас все устроено как я описал тут. Кейс про email я выбрал для наглядности, основная проблема у нас была с вакансиями, которые показываем в откликах кандидата (их могу видеть все, но в саму вакансию перейти не могут). Вероятно нет сложных кейсов потому, что это все таки кабинет в рамках компании, а не сайт hh.ru, где есть поконтактный доступ (часть полей может быть скрыто, но и это не проблема, их то как раз можно целиком выделять в алгебраический тип блоком - например ContactsItem и ContactsError)
У нас же у компании либо куплен доступ ко всему кабинету, либо нет. А для отдельных ролей могут быть просто видны названия чужих вакансий, или наоборот не видны чужие кандидаты (если откроют по прямой ссылке такого)
Зачем хранить курсоры? какой неожиданное? Курсор знает фронт и передает бэку
Иногда это id, но чаще я видел createdBefore (таймстамп). Клиент просто берет таймстамп последней сущности в списке и запрашивает очередную страницу сущностей
С ссылками да, не передать, но редко вижу чтобы ссылку передавали на список, а не на выбранный айтем
Причем тут тень или не тень?
Иллюзия в том, что уже затененную клетку B мы видимо более светлой, чем клетку A, хотя если глянуть пипеткой, то цвета в этих пикселях абсолютно одинаковые
Статья о том, как мы использовали вот эти два инструмента, и у нас все получилось и мы молодцы
А как получилось, мы не скажем. Вот только слайд с уравнениями для затравки.
Там допускаются к соревнованиям в 3 случаях (про финал не знаю, там не бывал):
1. Год рождения (ну просто по возрасту, я не помню если честно сколько именно максимум, но у меня он достигался после окончания вуза)
2. Прошло не более 6 лет с зачисления в вуз в первый раз
3. А вот тут не помню, было что-то третье.
Помню только еще, что в любом случае не более 5 раз участвовать (ну это про четверть и полуфинал)
А есть ли похожие соревнования, но для graduated?)
В том же ACM есть 3 вида допущения, и одно из них год рождения, и можно уже закончив ВУЗ проходить по году рождения (что я и делал целых 2 раза).
С чего это в двухмерном мире первой степени радиуса было бы? а в одномерном чему тогда?
Уравнение сферы содержит R^2 в любом кол-ве измерений, так что вообще не аргумент)
ну и соответственно тот самый кейс - запросили email, выдали вам null
как вам понять недоступен он или не заполнен? В массив errors писать можно об этом, но это неудобно (нет строгой типизации в ошибках, просто набор полей, перечисление типов ошибок). Получается что контракт по ошибкам хранится где-то в другом месте, а о сущностях - в схеме. Хочется чтобы было единое место знаний - схема.
Хороший вопрос, но о причинах перехода (они же примеры, и они же в итоге и дали профит) описано в другой нашей статье https://habr.com/ru/company/hh/blog/677972/
вы путаете обязательность заполнения и ответа)
NonNull (или восклицательный знак) означает не обязательность ответа, а то, Что если вы его запросили, оно точно не null. И избавляться от этих пометок это самое последнее что хочется делать. Клиенту хочется знать что всегда заполнено, а на что ему надо обрабатывать null-ы
GraphQL на то он и нужен, что никакой обязательности ответов нет, запрашивай что хочешь (иначе смысл?)
Может не понял про список полей, но у кандидата будет поле contacts типа Contacts, как-то так:
Да, могут быть разные блоки, еще например ФИО и день рождения, их можно целиком еще в один объект. Если прям хочется динамические блоки в зависимости от ролей, и динамически включать и выключать, то тут конечно придется уже наверное более синтетические списки этих самых полей в дженерном виде.
Пример достаточно топорный, там можно накручивать.. Могут быть полные и не полные контакты (будет три состояния, вообще недоступны, виден только часть, видны все). + со списками еще логика такая - выдаем то, что доступно тебе (когда запрашиваешь "мои вакансии", тут все как в обычном REST API)
Не очень понял с чего вывод про наверняка) И все таки, что значит "появляются всегда". Если речь о том, что есть место в приложении, где мы показываем маленькую часть объекта - так GraphQL и нужен для этого, клиент просит только эти поля.
В реальности у нас все устроено как я описал тут. Кейс про email я выбрал для наглядности, основная проблема у нас была с вакансиями, которые показываем в откликах кандидата (их могу видеть все, но в саму вакансию перейти не могут). Вероятно нет сложных кейсов потому, что это все таки кабинет в рамках компании, а не сайт hh.ru, где есть поконтактный доступ (часть полей может быть скрыто, но и это не проблема, их то как раз можно целиком выделять в алгебраический тип блоком - например ContactsItem и ContactsError)
У нас же у компании либо куплен доступ ко всему кабинету, либо нет. А для отдельных ролей могут быть просто видны названия чужих вакансий, или наоборот не видны чужие кандидаты (если откроют по прямой ссылке такого)
Иногда это id, но чаще я видел createdBefore (таймстамп). Клиент просто берет таймстамп последней сущности в списке и запрашивает очередную страницу сущностей
С ссылками да, не передать, но редко вижу чтобы ссылку передавали на список, а не на выбранный айтем
Иллюзия в том, что уже затененную клетку B мы видимо более светлой, чем клетку A, хотя если глянуть пипеткой, то цвета в этих пикселях абсолютно одинаковые
А как получилось, мы не скажем. Вот только слайд с уравнениями для затравки.
1. Год рождения (ну просто по возрасту, я не помню если честно сколько именно максимум, но у меня он достигался после окончания вуза)
2. Прошло не более 6 лет с зачисления в вуз в первый раз
3. А вот тут не помню, было что-то третье.
Помню только еще, что в любом случае не более 5 раз участвовать (ну это про четверть и полуфинал)
В том же ACM есть 3 вида допущения, и одно из них год рождения, и можно уже закончив ВУЗ проходить по году рождения (что я и делал целых 2 раза).