Repository navigation
Translation of blog post "2015-02-20-introducing-relay-and-graphql" - #312
Merged
Merged
Conversation
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 |
Ajuste do último parágrafo
sibelius
reviewed
Sep 5, 2019
sibelius
reviewed
Sep 5, 2019
dittrichlucas
suggested changes
Sep 5, 2019
| Essa colocação leva os desenvolvedores a cair no ["pit de sucesso"](https://english.stackexchange.com/a/77541), porque eles pegam exatamente os dados que eles pediram e os dados que eles pediram são definidos explicitamente, bem perto de onde foi usado. Isso significa que o desempenho vem por padrão (se torna muito difícil causar over-fetch acidentalmente), e os componentes são mais robustos (under-fetching também se torna menos provável pela mesma razão, então componentes não vão tentar renderizar dados que estão faltando e dar pau em tempo de execução). | ||
|
|
||
| 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?
| Só os campos de um objeto que um componente explicitamente pede serão acessíveis àquele componente, mesmo que outros campos sejam conhecidos e cacheados no store (porque outro componente pediu por eles). Isso faz com que seja impossível ocorrer bugs por dependências de dados implícitos posteriormente no sistema. | ||
|
|
||
| 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
suggested changes
Sep 5, 2019
| Nós estamos trabalhando duro atualmente para disponibilizar o GraphQL (uma especificação e uma implementação como referência) e o Relay ao público (sem datas específicas ainda, mas nós estamos super empolgados para trazê-los pra cá). | ||
|
|
||
| In the meantime, we'll be providing more and more information in the form of blog posts (and in [other channels](https://github.com/proxy/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://github.com/proxy/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. |
Contributor
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. |
Contributor
There was a problem hiding this comment.
Esta parte de getting the next page ficou um pouco sem nexo.
Co-Authored-By: Júlio Campos <jcserracampos@gmail.com>
Co-Authored-By: Júlio Campos <jcserracampos@gmail.com>
Co-Authored-By: Júlio Campos <jcserracampos@gmail.com>
Co-Authored-By: Júlio Campos <jcserracampos@gmail.com>
Contributor
Author
|
Mudanças propostas feitas |
jcserracampos
previously approved these changes
Sep 7, 2019
Contributor
Author
|
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 <jcserracampos@gmail.com>
renanmav
dismissed stale reviews from vitorebatista, jcserracampos, and dittrichlucas
via
September 8, 2019 13:31
0cd9a56
jcserracampos
approved these changes
Sep 8, 2019
jhonmike
approved these changes
Sep 9, 2019
devin-ai-integration Bot
pushed a commit
to WalissonRodrigo/pt-br.react.dev
that referenced
this pull request
Jul 9, 2026
…eactjs#312) * Update 2015-02-20-introducing-relay-and-graphql.md Tradução para PT-BR do primeiro parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução do segundo parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução do terceiro parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução do quarto parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução do quinto parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução do sexto parágrafo * Update 2015-02-20-introducing-relay-and-graphql.md Tradução dos dois primeiros itens da lista * Update 2015-02-20-introducing-relay-and-graphql.md Tradução dos penúltimos parágrafos * Update 2015-02-20-introducing-relay-and-graphql.md Tradução dos últimos parágrafos * Update 2015-02-20-introducing-relay-and-graphql.md Ajuste do último parágrafo * Update content/blog/2015-02-20-introducing-relay-and-graphql.md Co-Authored-By: Júlio Campos <jcserracampos@gmail.com> * Update content/blog/2015-02-20-introducing-relay-and-graphql.md Co-Authored-By: Júlio Campos <jcserracampos@gmail.com> * Mudanças propostas pela revisão * Update content/blog/2015-02-20-introducing-relay-and-graphql.md Co-Authored-By: Júlio Campos <jcserracampos@gmail.com> * Update content/blog/2015-02-20-introducing-relay-and-graphql.md Co-Authored-By: Júlio Campos <jcserracampos@gmail.com> * Update 2015-02-20-introducing-relay-and-graphql.md * Update 2015-02-20-introducing-relay-and-graphql.md * Update content/blog/2015-02-20-introducing-relay-and-graphql.md Co-Authored-By: Júlio Campos <jcserracampos@gmail.com>
This file contains hidden or 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
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