Translation of blog post "2015-02-20-introducing-relay-and-graphql" #312
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Tradução para PT-BR do primeiro parágrafo
Tradução do segundo parágrafo
Tradução do terceiro parágrafo
Tradução do quarto parágrafo
Tradução do quinto parágrafo
Tradução do sexto parágrafo
Tradução dos dois primeiros itens da lista
Tradução dos penúltimos parágrafos
Tradução dos últimos parágrafos
|
Deploy preview for pt-br-reactjs ready! Built with commit 4f3dd6b |
jcserracampos
added
blog
Ajuste do último parágrafo
sibelius
reviewed
Sep 5, 2019
sibelius
reviewed
Sep 5, 2019
dittrichlucas
suggested changes
Sep 5, 2019
|
|
||
| Relay provides a predictable environment for developers by maintaining an invariant: a component won't be rendered until all the data it requested is available. Additionally, queries are defined statically (ie. we can extract queries from a component tree before rendering) and the GraphQL schema provides an authoritative description of what queries are valid, so we can validate queries early and fail fast when the developer makes a mistake. | ||
| Relay provêm um ambiente previsível para desenvolvedores mantendo uma constante: um componente não será renderizado até que todos os dados requeridos estejam disponíveis. Adicionalmente, queries são definidas estaticamente (ou seja, nós podemos extrair as queries da árvore de um componente antes da renderização) e o schema do GraphQL provê uma descrição autoritária de quais queries são válidas, então nós podemos validar as queries logo cedo e falhar rapidamente quando o desenvolver cometer um erro. |
There was a problem hiding this comment.
Acredito que deve ser prove ao invés de provêm, certo?
|
|
||
| By handling all data-fetching via a single abstraction, we're able to handle a bunch of things that would otherwise have to be dealt with repeatedly and pervasively across the application: | ||
| Com o manuseio de todo o data-fetching através de uma única abstração, nós somos capazes de lidar com um monte de coisas que de outra forma teriam que ler lidadas de forma repetitiva por toda aplicação: |
| - **Common patterns:** We can make common patterns easy. Pagination is the example that [Jing](https://twitter.com/jingc) gave at the conference: if you have 10 records initially, getting the next page just means declaring you want 15 records in total, and the framework automatically constructs the minimal query to grab the delta between what you have and what you need, requests it, and re-renders your view when the data become available. | ||
| - **Simplified server implementation:** Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources. | ||
| - **Uniform mutations:** There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back. | ||
| - **Performance:** Todas as queries seguem pelo fluxo do framework, onde coisas que de outra forma seriam ineficientes, padrões repetidos de queries são automaticamente colapsadas em lotes eficientes, queries mínimas. Da mesma forma, o framework sabe quais dados foram previamente pedidos, ou quais requisições ainda estão acontecendo, assim, queries podem ser "disduplicadas" e queries mínimas podem ser produzidas. |
There was a problem hiding this comment.
desduplicadas ao invés de disduplicadas
jcserracampos
requested changes
Sep 5, 2019
|
|
||
| In the meantime, we'll be providing more and more information in the form of blog posts (and in [other channels](https://gist.github.com/wincent/598fa75e22bdfa44cf47)). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more. | ||
| No meio tempo, nós estaremos disponibilizando mais e mais informações na forma de posts de blog (e em [outros canais](https://gist.github.com/wincent/598fa75e22bdfa44cf47)). À medida que chegamos perto do lançamento open source, vocês podem esperar por detalhes mais concretos, sintaxe, documentações de API e mais. |
There was a problem hiding this comment.
Uma palavra que não existe em português, mas usamos muito é post.
Recomendo usar publicação, artigo ou algo do gênero.
| - **Uniform mutations:** There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back. | ||
| - **Performance:** Todas as queries seguem pelo fluxo do framework, onde coisas que de outra forma seriam ineficientes, padrões repetidos de queries são automaticamente colapsadas em lotes eficientes, queries mínimas. Da mesma forma, o framework sabe quais dados foram previamente pedidos, ou quais requisições ainda estão acontecendo, assim, queries podem ser "disduplicadas" e queries mínimas podem ser produzidas. | ||
| - **Subscriptions:** Todos os dados fluem em um único store, e todas as leituras do store são feitas via framework. Isso significa que o framework sabe quais componentes precisam de quais dados e quais deles devem ser re-renderizados quando os dados mudarem; componentes nunca têm que setar subscriptions individuais. | ||
| - **Padrões comuns:** Nós podemos fazer com que padrões comuns se tornem fáceis. Paginação é o exemplo que o [Jing](https://twitter.com/jingc) deu na conferência: se você tem 10 registros inicialmente, pegar a próxima página só quer dizer que você quer 15 registros no total, e o framework automaticamente constrói a query mínima para pegar a diferença entre o que você tem e o que você precisa, faz a requisição e re-renderiza o componente quando os dados se tornam disponíveis. |
There was a problem hiding this comment.
Esta parte de getting the next page ficou um pouco sem nexo.
jhonmike
added
needs author response
Co-Authored-By: Júlio Campos <[email protected]>
Co-Authored-By: Júlio Campos <[email protected]>
Co-Authored-By: Júlio Campos <[email protected]>
Co-Authored-By: Júlio Campos <[email protected]>
|
Mudanças propostas feitas |
jcserracampos
previously approved these changes
Sep 7, 2019
|
Há mais reviewers? |
dittrichlucas
previously approved these changes
Sep 7, 2019
jcserracampos
previously approved these changes
Sep 7, 2019
vitorebatista
previously approved these changes
Sep 8, 2019
Co-Authored-By: Júlio Campos <[email protected]>
renanmav
dismissed stale reviews from vitorebatista, jcserracampos, and dittrichlucas
via
0cd9a56
jcserracampos
approved these changes
Sep 8, 2019
jhonmike
approved these changes
Sep 9, 2019
jhonmike
removed
the
needs author response
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #302
Post original: https://reactjs.org/blog/2015/02/20/introducing-relay-and-graphql.html
Post traduzido: https://github.com/renanmav/pt-BR.reactjs.org/blob/patch-1/content/blog/2015-02-20-introducing-relay-and-graphql.md