OG
выглядит очень круто
Size: a a a
2019 August 08
e
Как вы в 2019 с базой работаете, все с орм?
смотря где, мне нравится решение в scala -> slick (не орм решение)
2019 August 09
OG
кто то сталкивался с ✖ An unknown error happened: java.lang.ClassCastException: com.prisma.shared.models.TypeIdentifier$Relation$ cannot be cast to com.prisma.shared.models.TypeIdentifier$ScalarTypeIdentifier
P@
Я вообще своих ругаю за то, что хранят запросы и фрагменты вне компонент (в отдельных файлах).
P@
Поэтому у нас нет ни одного .gql . graphql файла.
Связано это с тем, чтобы не было возможности использования одного запроса/фрагмента в разных компонентах. Это черевато тем, что в будущем кто-то правя запрос, сломает какой-то компонент о котором даже и не знал.
Связано это с тем, чтобы не было возможности использования одного запроса/фрагмента в разных компонентах. Это черевато тем, что в будущем кто-то правя запрос, сломает какой-то компонент о котором даже и не знал.
P@
Поэтому чтоб ничего не ломалось, графкуэльные запросы и фрагменты храняться в тех файлах где непосредственно используются. Точно также как и в Фейсбуке.
BS
Всем привет, <Query>{() => <Query>{() => ...}</Query>}</Query>
юзать вот так вот это не есть хорошо? тоесть внутри если квери нужен, то его нужно выполнить именно в дочернем компоненте?
юзать вот так вот это не есть хорошо? тоесть внутри если квери нужен, то его нужно выполнить именно в дочернем компоненте?
BS
Поэтому у нас нет ни одного .gql . graphql файла.
Связано это с тем, чтобы не было возможности использования одного запроса/фрагмента в разных компонентах. Это черевато тем, что в будущем кто-то правя запрос, сломает какой-то компонент о котором даже и не знал.
Связано это с тем, чтобы не было возможности использования одного запроса/фрагмента в разных компонентах. Это черевато тем, что в будущем кто-то правя запрос, сломает какой-то компонент о котором даже и не знал.
лол, а если запрос будет довольно обьемный, вы его все равно в компоненте делаете?
P@
лол, а если запрос будет довольно обьемный, вы его все равно в компоненте делаете?
Мы его дробим на компоненты с фрагментами
BS
Мы его дробим на компоненты с фрагментами
P@
Если запросы писать целиком, то это ничем не отличается от REST подхода, когда запрос пишется наверху.
BS
Если запросы писать целиком, то это ничем не отличается от REST подхода, когда запрос пишется наверху.
вынести в gql, если запрос юзается много где, вынести на урвоень выше, в папку gql/query либо mutations
P@
Когда мне мои говорят что запрос и компонент большой. То я говорю бейте запрос на фрагменты и бейте рендер, вынося их в отдельный файл.
NK
Привет всем нужно провести тестирования алгоритма за вознаграждение писать сюда
https://cutt.ly/7wymXtC
https://cutt.ly/7wymXtC
AL
Когда мне мои говорят что запрос и компонент большой. То я говорю бейте запрос на фрагменты и бейте рендер, вынося их в отдельный файл.
+1. Полостью согласен с тобой. Что на практике, что в теории, это лучше и проще поддерживать в разы.
AL
Data requirements получаются чистейшие
AL
У компонента
AL
А с кодо генерацией и TS, это вообще иисусье
A1
Если кто-то пишет на graphene + sqlalchemy и ему не хватает удобной фильтрации, то я там либу написал https://github.com/art1415926535/graphene-sqlalchemy-filter
2019 August 10
e
Если кто-то пишет на graphene + sqlalchemy и ему не хватает удобной фильтрации, то я там либу написал https://github.com/art1415926535/graphene-sqlalchemy-filter
полезно, лайк