ДН
ну тогда кастомный тип JSON и в путь)
ну я так и сделал
Size: a a a
2020 May 01
2020 May 02
D
Всем привет кто нибудь использовал mobx + graphql ?
D
Если да,то как вы делали запросы в mobx ?
И
ну вот довольно типичный кейс, когда мне нужно отдавать массивы с именноваными ключами, для мультиязычности
А в общем и целом в чём отличие объекта от массива?
Какая принципиальная разница между
Какая принципиальная разница между
{ foo: {...} } и [{ key: “foo”, ...}]?ДН
ДН
ну представь item.name[$i18n.locale] и тоже самое в случае если ключа нет
ну это как пример, когда нужны сразу два поля, то без ключа был бы ад
M
ну тут всего лишь ОДНУ дополнительную фунцию нужно будет написать, getNameByLocale
И
ну представь item.name[$i18n.locale] и тоже самое в случае если ключа нет
Делаешь параметризованый query для получения локали по ключу / по двум ключам / по массиву ключей, получаешь данные, а на фронте как хочешь их хранишь. Хочешь — в хэшмапе, хочешь — в сэте.
ДН
M
ну тут всего лишь ОДНУ дополнительную фунцию нужно будет написать, getNameByLocale
такие функции не самый хороший друг реактивности
ДН
Делаешь параметризованый query для получения локали по ключу / по двум ключам / по массиву ключей, получаешь данные, а на фронте как хочешь их хранишь. Хочешь — в хэшмапе, хочешь — в сэте.
зачем такие сложности?
И
зачем такие сложности?
Чтобы соблюдать протокол GraphQL и хранить типизированную схему вместо абстрактного JSON
ДН
Чтобы соблюдать протокол GraphQL и хранить типизированную схему вместо абстрактного JSON
но мне нужен был именно абстрактный json
M
а прикинь если придётся мобильный клиент писать, а там java, разраб охуфигеет для каждого твоего объекта новый класс создавать с абсолютно идентичными полями, это херовая практика хранить значение в ключах, ключи на то и ключи, а не значения
ДН
но мне нужен был именно абстрактный json
я выше писал что у меня json может быть каким угодно
И
M
а прикинь если придётся мобильный клиент писать, а там java, разраб охуфигеет для каждого твоего объекта новый класс создавать с абсолютно идентичными полями, это херовая практика хранить значение в ключах, ключи на то и ключи, а не значения
Разраб, скорее всего уже слышал про фабрики, которые плодят объекты и не офигевают
ДН
M
а прикинь если придётся мобильный клиент писать, а там java, разраб охуфигеет для каждого твоего объекта новый класс создавать с абсолютно идентичными полями, это херовая практика хранить значение в ключах, ключи на то и ключи, а не значения
тоесть? Зачем для каждого новый класс? Все что возвращает у меня такие данные использует один тип
И
я выше писал что у меня json может быть каким угодно
Тогда это просто String
ДН
Тогда это просто String
он клиенту как json будет уже прилетать?
И
я выше писал что у меня json может быть каким угодно
Я думал, мы про ассоциативные массивы в gql, а не про непредсказуемые структуры
ДН
