Conversation
| @@ -0,0 +1,19 @@ | |||
| open Js.Promise; | |||
|
|
|||
| module Make = (Config: ReasonApolloTypes.Config) => { | |||
There was a problem hiding this comment.
Ten moduł w końcu mi się nie przydał - służy do puszczania requestów graphqlowych bez używania komponentu.
Ale może się w przyszłości okazać przydatny dlatego go narazie nie skasowałem
There was a problem hiding this comment.
"bez używania komponentu"? Co to dokładnie oznacza i jaka jest różnica pomiędzy jednym a drugim?
Mimo wszystko trzeba też się głębiej zastanowić, czy w przyszłości się z tego pliku na pewno skorzysta. Bo tak minie parę miesięcy, a ten plik nadal nie zostanie użyty :P.
There was a problem hiding this comment.
Reaon-apollo dostarcza komponent który na zamontowanie sam pobiera dane. Później można wymusić na nim refetch - zorobiłem wyżej za pomocą tego refetchUsersList - i w zasadzie tyle on potrafi. A czasem mogą być sytuacje że można trzeba jakoś bardziej customowo pobierać dane - np. nie na zamontowanie ale na jakąś akcję. Albo, jeśli chcielibyśmy trzymać dane w stanie komponentu, to wtedy właśnie można użyć tego. To pozwala ręcznie strzelać do be i to coś zwraca promisę. Narazie bym zostawił do momentu zakończenia przepisywania na gql, jeśli po tym będzie niepotrzebny to będzei można wywalić
|
Oczywiście domergowanie tego oznacza że teraz czeka nas znowu krucjata przerabiająca cały BE - oczywiście nie muszę ja wszystkiego robić jeśli chcecie poznać graphqla. Ale jeśli nie ma zapału i chęci na graphqla (mi się pewnie samemu całości nie będzie chciało przerabiać) nie muszę tego mergować i możeby pozostać przy REST. Jak chceta ! |
|
Ja tam jak najbardziej mogę się wkręcić, bo potrzebuję dowiedzieć się o wiele więcej o GraphQL. Nie mniej, może to trochę potrwać :/. |
To według mnie można dodać adnotację |
be/Controller/GraphQLCtrl.php
Outdated
| use GraphQLElo\Resolvers\UsersResolver; | ||
| use GraphQLElo\Types\UserType; | ||
|
|
||
| class GraphQLCtrl { |
There was a problem hiding this comment.
Nie stosuje się (raczej) dwóch dużych liter obok siebie w środku nazwy klasy. Zmniejsza czytelność. Może po prostu GqlCtrl?
be/Controller/GraphQLCtrl.php
Outdated
| $rawInput = $request->getBody(); | ||
| $input = json_decode($rawInput, true); | ||
| $query = $input['query']; | ||
| $variableValues = isset($input['variables']) ? $input['variables'] : null; |
There was a problem hiding this comment.
Tutaj można zmienić tą linijkę na:
$variableValues = $input['variables'] ?? null;
be/Controller/GraphQLCtrl.php
Outdated
| return $response->withJson($output); | ||
| } | ||
|
|
||
| private function getQueryFields() { |
There was a problem hiding this comment.
Uzupełnić typowanie :array
| use Model\Entity\User; | ||
| use Model\Repository\UserRepository; | ||
|
|
||
| class UsersResolver { |
There was a problem hiding this comment.
Zakładam, że resolvery służą do przetworzenia parametrów Requesta i na ich podstawie zwrócenia odpowiednich danych? Czy tutaj w jakiś sposób czasem te parametry nie powinny być przekazywane? Chodzi mi o to, że np. czy kod ['rating' => 'DESC', 'code' => 'ASC'] nie powinien czasem być jakoś przekazywany jako parametr mówiący o tym według czego ma być sortowanie?
There was a problem hiding this comment.
Tak, możnaby zrobić jakiś input typ który by tym sterował i wtedy możnaby tym sterować z FE, ale narazie to jest wprowadzenie graphqlea - narazie bym zostawł w przyszłości jak będzie potrzeba będzie można to oczywiście zmienić
be/GraphQLElo/Types/UserType.php
Outdated
| 'fields' => [ | ||
| 'userNid' => [ | ||
| 'type' => Type::nonNull(Type::int()), | ||
| 'resolve' => function (User $user) { |
There was a problem hiding this comment.
Tego dowiedziałem się od nowego PhpStorma. Jak zrobić static function zamiast samego function, to będzie to bardziej optymalne :).
| @@ -0,0 +1,6 @@ | |||
| let inMemoryCache = ApolloInMemoryCache.createInMemoryCache(); | |||
There was a problem hiding this comment.
Czy nie powinniśmy nazwać tego pliku jakoś inaczej? Np. GqlClient, albo ApiClient (lub podobne)? W przyszłości, jak dojdzie jakikolwiek inny "Client", to będzie problem.
| } | ||
| </div>, | ||
| <GetUsersQuery | ||
| notifyOnNetworkStatusChange=true variables=usersQuery##variables> |
There was a problem hiding this comment.
variables=usersQuery##variables
Cóż to za konstrukcja?
notifyOnNetworkStatusChange
Cóż to za parametr?
There was a problem hiding this comment.
-
variables=usersQuery##variables -
Jeśli chodzi Ci o pytanie co to jest ## to to jest poprostu pobranie elementu z obiektu. usersQuery to obiekt Js.t i z niego pobiera się parametry właśnie w taki sposób.
A ogólnie to jest to przekazanie parametrów do zapytania graphqlowego. To wziąłem dokładnie z dokumentacji reason-apollo: https://github.com/apollographql/reason-apollo -
notifyOnNetworkStatusChange to już jest mniej oczywiste. Generalnie ten komponent zwraca dane i domyślnie obsługuje tylko pokazanie loading gdy pobiera dane za pierwszym razem. Dzięki temu parametrowi, przy obieraniu danych mamy parametr networkStatus z którego można wyciągnąć czy dane pobierane są ponownie - żeby pokazać loading.
| ResponseDecoder.MakeWithWarningsOrContent(GameResponseContentDecoder); | ||
|
|
||
| let onSuccess = (containterSend, send, json) => { | ||
| let onSuccess = (refreshUsers, send, json) => { |
There was a problem hiding this comment.
Nazwa dla tego na pewno lepsza, ale jakoś "refresh" mi tu też nie pasuje :D. Ja bym przerobił na "reloadUsersList".
| ...{ | ||
| ({result, refetch, networkStatus}) => { | ||
| let refreshUsers = refreshUsersWithRefetch(refetch); | ||
| let isRefeching = networkStatus == Some(4); |
There was a problem hiding this comment.
Trzeba by wyjaśnić nieco co oznacza Some(4).
There was a problem hiding this comment.
To się właśnie wiąże troche z powyższym pytaniem. Akurat Some(4) oznacza że dane pobierają się ponownie - tak mają w dokumentacji react-apollo. Wyniosłem to do stałej
Niewiem czy to co pisałem wyżej i tutaj jest zrozumiałe jak coś mogę potłumaczyć na żywo.
|
|
||
| let onSuccess = (send, json) => | ||
| json |> DecodeUsers.users |> (users => send(SetUsersToState(users))); | ||
| let refreshUsersWithRefetch = (refetch, ()) => refetch(None)->ignore; |
There was a problem hiding this comment.
Wyjaśnisz mi, proszę, co oznacza refetch(None)->ignore ?
There was a problem hiding this comment.
refetch to funkcja dostarczona przez reason-apollo która ponownie wysyła request o pobranie danych.
Ona właśnie powoduje że wysyła się request i wtedy ten komponent wygenerowany z reason-apollo (GetUsersQuery) sam się odświży - i to chce osiągnąć. Ale ta funkcja dodaktowo zwraca promise, jeśli ktoś chciałby potem coś jeszcze robić. Ja nie chce i po to jest ten ignore - bo funkcja refreshUsersWithRefetch powinna zwrócić unita, a bez użycia ignore by zwróciła promise. Czyli w skrócie ignore to funkcja która bierze coś tam i zwraca unita.
be/Controller/GraphQLCtrl.php
Outdated
| use GraphQLElo\Resolvers\UsersResolver; | ||
| use GraphQLElo\Types\UserType; | ||
|
|
||
| class GraphQLCtrl { |
be/Controller/GraphQLCtrl.php
Outdated
| $rawInput = $request->getBody(); | ||
| $input = json_decode($rawInput, true); | ||
| $query = $input['query']; | ||
| $variableValues = isset($input['variables']) ? $input['variables'] : null; |
be/Controller/GraphQLCtrl.php
Outdated
| return $response->withJson($output); | ||
| } | ||
|
|
||
| private function getQueryFields() { |
| use Model\Entity\User; | ||
| use Model\Repository\UserRepository; | ||
|
|
||
| class UsersResolver { |
There was a problem hiding this comment.
Tak, możnaby zrobić jakiś input typ który by tym sterował i wtedy możnaby tym sterować z FE, ale narazie to jest wprowadzenie graphqlea - narazie bym zostawł w przyszłości jak będzie potrzeba będzie można to oczywiście zmienić
be/GraphQLElo/Types/UserType.php
Outdated
| 'fields' => [ | ||
| 'userNid' => [ | ||
| 'type' => Type::nonNull(Type::int()), | ||
| 'resolve' => function (User $user) { |
| let component = ReasonReact.statelessComponent("RankAndStats"); | ||
|
|
||
| let component = ReasonReact.reducerComponent("RankAndStats"); | ||
| module GetUsers = [%graphql |
There was a problem hiding this comment.
Nawiązując do pytania o ppx - to właśnie tutaj to jest użyte - dzięki tamtemu w bsconfig można tutaj zrobić takie zapytanie graphqlowe o takiej składni
| } | ||
| </div>, | ||
| <GetUsersQuery | ||
| notifyOnNetworkStatusChange=true variables=usersQuery##variables> |
There was a problem hiding this comment.
-
variables=usersQuery##variables -
Jeśli chodzi Ci o pytanie co to jest ## to to jest poprostu pobranie elementu z obiektu. usersQuery to obiekt Js.t i z niego pobiera się parametry właśnie w taki sposób.
A ogólnie to jest to przekazanie parametrów do zapytania graphqlowego. To wziąłem dokładnie z dokumentacji reason-apollo: https://github.com/apollographql/reason-apollo -
notifyOnNetworkStatusChange to już jest mniej oczywiste. Generalnie ten komponent zwraca dane i domyślnie obsługuje tylko pokazanie loading gdy pobiera dane za pierwszym razem. Dzięki temu parametrowi, przy obieraniu danych mamy parametr networkStatus z którego można wyciągnąć czy dane pobierane są ponownie - żeby pokazać loading.
| ...{ | ||
| ({result, refetch, networkStatus}) => { | ||
| let refreshUsers = refreshUsersWithRefetch(refetch); | ||
| let isRefeching = networkStatus == Some(4); |
There was a problem hiding this comment.
To się właśnie wiąże troche z powyższym pytaniem. Akurat Some(4) oznacza że dane pobierają się ponownie - tak mają w dokumentacji react-apollo. Wyniosłem to do stałej
Niewiem czy to co pisałem wyżej i tutaj jest zrozumiałe jak coś mogę potłumaczyć na żywo.
| @@ -0,0 +1,6 @@ | |||
| let inMemoryCache = ApolloInMemoryCache.createInMemoryCache(); | |||
| @@ -0,0 +1,19 @@ | |||
| open Js.Promise; | |||
|
|
|||
| module Make = (Config: ReasonApolloTypes.Config) => { | |||
There was a problem hiding this comment.
Reaon-apollo dostarcza komponent który na zamontowanie sam pobiera dane. Później można wymusić na nim refetch - zorobiłem wyżej za pomocą tego refetchUsersList - i w zasadzie tyle on potrafi. A czasem mogą być sytuacje że można trzeba jakoś bardziej customowo pobierać dane - np. nie na zamontowanie ale na jakąś akcję. Albo, jeśli chcielibyśmy trzymać dane w stanie komponentu, to wtedy właśnie można użyć tego. To pozwala ręcznie strzelać do be i to coś zwraca promisę. Narazie bym zostawił do momentu zakończenia przepisywania na gql, jeśli po tym będzie niepotrzebny to będzei można wywalić
Zrobiłem endpoint api graphqlowego pod adresem .../api/graphql
Jest tam narazie tylko jeden węzeł: users - służy do pobierania userów do rankingu.
Po stronie fe przerobiłem właśnie pobieranie ludzików do rankingu aby korzystać z tego węzła (zamiast z restowego: /users. Restowego serwisu nie usunąłem bo Stats z niego korzysta - oczywiście tam też będzie można przerobić aby korzystało z graphqlowego węzła - ale to może w następnych kejsach).
To jest narazie pierwszy krok - w którym tylko pobieram dane. W innych kejsach w miarę przerabiania aplikacji trzeba będzie ogarnąć głównie dwie rzeczy: