Blog Acordo Coletivo atinge 3.400.000 leituras e 25.000 artigos selecionados


3.600.000 em dez/2016 – 25800 artigos

3.000.000 em fev/2016

1.500.000 em 29/03/2013

2.400.000 em 25/05/2015

1.000.000 por ano

25000 posts em outubro de 2016. 5 anos de vida. 25000/5=5000 posts por ano, uns 500 por mes, uns 25 posts selecionados por dia útil

Criação do Blog: 23/11/2011 – 1 2 3 4 5 – 5 anos em 23/11/2016

Média de Posts

25000/5 = 5000 posts por ano = 500 post por mês = em torno de 20 posts por cada 25 dias (consideramos os dias uteis , e sábado e domingo como um só dia)

criado em 23 de novembro de 2011

Blog Acordo Coletivo atinge 1.000.000 de leituras e 10.000 artigos

Em fevereiro de 2013
16000 artigos – media: 1.000 artigos / mes = 50 artigos selecionados por dia util
6000 comentários
1.450.000 acessos

Opinião do Leitor sobre o blog Acordo Coletivo


Coloque neste post sua opiniao sobre o nosso trabalho.
Caso você avalie o blog abaixo de regular, agradeceríamos informar o que pode/deve ser melhorado.

Avalie aqui. Dê uma opinião ou sugestão aqui.

Visitors 2016 inicio 25/2/2016
Flag Counter

Aqui

Visitors colocado recentemente (13/10/2010)

free counters

Locations of visitors to this page

[lista geral de posts e assuntos]

A colocacao de opinioes, criticas e sugestoes e’ bem-vinda e e’ colocada neste post atraves do reply.

Obrigado.

Editores.

Apoios: http://br.groups.yahoo.com/group/Acordo_Coletivo_Petrobras/

http://br.groups.yahoo.com/group/cipas_br

http://br.groups.yahoo.com/group/oab_provas

http://br.groups.yahoo.com/group/sindipetros_br

Offline First


We live in a disconnected & battery powered world, but our technology and best practices are a leftover from the always connected & steadily powered past.

Offline capability is a key characteristic of modern Progressive Web Applications. Offline first thinking must learn from and further what we’ve seen work with Responsive and Mobile First thinking.

Read the introduction and then follow up on A List Apart. Visit or organise a local event, join the Offline First Chat, or check out additional resources.

We want to spark a discussion around:

  • UI Conventions for Offline Apps
  • UX patterns
  • User research
  • Mental model discovery
  • Tools and techniques for building offline capable apps
  • Distributed systems research
  • Technology solutions for handling offline
  • Web and Native

We are collecting discussion results from all of the above on our Offline First Github Organisation.

Visual Studio Code


Origem: Wikipédia, a enciclopédia livre.
Visual Studio Code
Captura de tela

Visual Studio Code rodando no Windows 7, com a função “Search” ativada

Desenvolvedor Microsoft
Plataforma IA-32x64
Lançamento 29 de abril de 2015 (2 anos)
Versão estável [+/-]
Versão em teste [+/-]
Idioma(s) inglês, francês, alemão, italiano, japonês, coreano, russo, espanhol, chinês (tanto simplificado como tradicional)
Linguagem TypeScript, JavaScriptCSS
Sistema operacional Windows 7 ou versão posterior, OS X 10.10 ou versão posterior, Linux
Gênero(s) editor de código-fontedepurador
Licença
Tamanho
  • Windows: 32,8 MB
  • Debian, Ubuntu: 34,1 MB
  • Fedora, Red Hat: 50,4 MB
  • macOS: 51,8 MB
Página oficial code.visualstudio.com

Visual Studio Code é um editor de código-fonte desenvolvido pela Microsoft para WindowsLinux e macOS. Ele inclui suporte para depuração, controle Git incorporado, realce de sintaxe, complementação inteligente de código, snippets e refatoração de código. Ele também é customizável, fazendo com que os usuários possam mudar o tema do editor, teclas de atalho e preferências. Ele é um software livre e de código aberto,[4][5] apesar do download oficial estar sob uma licença proprietária.[3]

O Visual Studio Code é baseado no Electron, uma framework que é usada para desenvolver aplicativos Node.js para o desktop rodando no motor de layout Blink. Apesar de usar o Electron como framework,[6] o software não usa o Atom e em seu lugar emprega o mesmo componente editor (codenomeado “Monaco”) usado no Visual Studio Team Services (anteriormente chamado de Visual Studio Online).[7]

História[editar | editar código-fonte]

O Visual Studio Code foi anunciado, com uma versão de previsão lançada, em 29 de abril de 2015 pela Microsoft na conferência Build de 2015.[8]

Em 18 de novembro de 2015, o Visual Studio Code foi lançado sob a Licença MIT e o seu código-fonte foi postado no GitHub. Suporte para extensões também foi anunciada.[4]

Em 14 de abril de 2016, o Visual Studio Code concluiu o estágio de previsão pública e foi lançado para a web.[9]

Recursos[editar | editar código-fonte]

O Visual Studio Code é um editor de código-fonte. Ele suporta um número de linguagens de programação e um conjunto de recursos que podem ou não estarem disponíveis para a dada linguagem, como mostrado na tabela a seguir. Muitos dos recursos do Visual Studio Code features não são expostos através de menus ou da interface de usuário. Ao invés disso, elas estão acessíveis através da paleta de comandos ou or meio de um arquivo.json (como as preferências do usuário).[10] A paleta de comandos é uma interface de linha de comandos. No entanto, ele desaparece se o usuário clicar em qualquer lugar fora dele ou pressiona uma combinação de teclas no teclado para interagir com algo fora dela. Isso também é válido para comandos de time-taking. Quando isso acontece, o comando em andamento é cancelado.

No papel de um editor de código fonte, o Visual Studio Code permite alterar a página de código na qual o documento atual é salvo, o caractere que identifica quebra de linha (uma escolha entre CR e CRLF), e a linguagem de programação do documento ativo.

Recursos dependentes de linguagem[10]
Recursos Linguagens
Realce de sintaxe BatchC++ClojureCoffeeScriptDockerFileElixirF#Go, Pug template language,[11][12] Java, HandleBars, INILua, Makefile, Objective-CPerlPowerShellPythonR, Razor, RubyRustSQLVisual BasicXML
Snippets GroovyMarkdown, Nim,[13] PHPSwift
Complementação inteligente de código CSSHTMLJavaScriptJSONLess, Sass, TypeScript
Refatoração C#, TypeScript
Depuração

O Visual Studio Code pode ser estendido através de plugins,[14] disponíveis através de um repositório central. Isso inclui adições ao editor[15] e suporte para linguagens de programação.[10] Uma característica notável é a capacidade de criar extensões que analisam código, como linters e ferramentas para análise estática, usando o Language Server Protocol.[16]

Coleta de dados[editar | editar código-fonte]

O Visual Studio Code coleta dados de uso e os envia para a Microsoft, apesar deste recurso poder ser desabilitado pelo usuário.[17] Os dados são compartilhados entre afiliadas e subsidiárias controladas pela Microsoft e com a aplicação da lei por declaração de privacidade.[18]

Performance[editar | editar código-fonte]

O Visual Studio Code tem um uso muito alto de CPU apenas para mostrar o cursor intermitente.[19]

Ver também[editar | editar código-fonte]

Referências

  1. Ir para cima «LICENSE.txt»github.com/Microsoft/vscode (em inglês). Microsoft. 17 de novembro de 2015
  2. Ir para cima «Download Visual Studio Code»code.visualstudio.com (em inglês). Microsoft. Consultado em 16 de agosto de 2016
  3. ↑ Ir para:a b «Microsoft Software License Terms»code.visualstudio.com (em inglês). Microsoft. Consultado em 16 de agosto de 2016
  4. ↑ Ir para:a b «Visual Studio now supports debugging Linux apps; Code editor now open source» (em inglês). Ars Technica. Consultado em 18 de novembro de 2015
  5. Ir para cima Lardinois, Frederic (29 de abril de 2015). «Microsoft Launches Visual Studio Code, A Free Cross-Platform Code Editor For OS X, Linux And Windows» (em inglês). TechCrunch
  6. Ir para cima «Microsoft’s new Code editor is built on Google’s Chromium» (em inglês). Ars Technica. Consultado em 18 de novembro de 2015
  7. Ir para cima «Monaco Editor»microsoft.github.io/monaco-editor (em inglês)
  8. Ir para cima Montgomery, John (29 de abril de 2015). «BUILD 2015 News: Visual Studio Code, Visual Studio 2015 RC, Team Foundation Server 2015 RC, Visual Studio 2013 Update 5» (em inglês)
  9. Ir para cima «Visual Studio Code editor hits version 1, has half a million users» (em inglês). Ars Technica. 15 de abril de 2016
  10. ↑ Ir para:a b c «Language Support in Visual Studio Code» (em inglês). Visual Studio Code. 10 de outubro de 2016. Consultado em 12 de outubro de 2016
  11. Ir para cima «pugjs.org»
  12. Ir para cima «standalone-languages/jade.ts»Microsoft/vscode GitHub repository (em inglês). Microsoft. 13 de novembro de 2015
  13. Ir para cima «Nim Wiki: Editor Support» (em inglês)
  14. Ir para cima «Extending Visual Studio Code» (em inglês). Visual Studio Code. 10 de outubro de 2016. Consultado em 12 de outubro de 2016
  15. Ir para cima «Managing Extensions in Visual Studio Code» (em inglês). Visual Studio Code. 10 de outubro de 2016. Consultado em 12 de outubro de 2016
  16. Ir para cima «Creating Language Servers for Visual Studio Code» (em inglês). Consultado em 27 de fevereiro de 2017
  17. Ir para cima «Visual Studio Code FAQ» (em inglês). Consultado em 4 de novembro de 2016Cópia arquivada em 28 de agosto de 2016VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more. If you don’t wish to send usage data to Microsoft, you can set the telemetry.enableTelemetry setting to false.
  18. Ir para cima «Microsoft Enterprise and Developer Privacy Statement». Consultado em 4 de novembro de 2016Cópia arquivada em 4 de novembro de 2016
  19. Ir para cima «Blinking Cursor Devours CPU Cycles in Visual Studio Code Editor» (em inglês)

Ligações extermas[editar | editar código-fonte]

Visual Studio Code


Visual Studio Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux. It comes with built-in support for JavaScript, TypeScript and Node.js and has a rich ecosystem of extensions for other languages (such as C++, C#, Python, PHP, Go) and runtimes (such as .NET and Unity). Begin your journey with VS Code with these introductory videos.

Visual Studio Code in Action

Top Extensions

Enable additional languages, themes, debuggers, commands, and more. VS Code’s growing community shares their secret sauce to improve your workflow.

See more in the Marketplace

First Steps

To get the most out of Visual Studio Code, start by reviewing a few introductory topics:

Intro Videos – Begin your journey with VS Code through these introductory videos.

Setup – Install VS Code for your platform and configure the tool set for your development needs.

User Interface – Introduction to the basic UI, commands, and features of the VS Code editor.

Settings – Customize VS Code for how you like to work.

Languages – Learn about VS Code’s support for your favorite programming languages.

Node.js – This tutorial gets you quickly running and debugging a Node.js web app.

Community – Connect with the VS Code community and check out other ways to learn VS Code.

Why VS Code? – Read about the design philosophy and architecture of VS Code.

Keyboard Shortcuts

Increase your productivity with VS Code’s keyboard shortcuts.

Keyboard Shortcut Reference Sheet – Learn the commonly used keyboard shortcuts.

Keymap Extensions – Change VS Code’s keyboard shortcuts to match another editor.

Customize Keyboard Shortcuts – Modify the default keyboard shortcuts.

Downloads

Download VS Code – Quickly find the appropriate install for your platform (Windows, macOS and Linux).

Privacy

By default, VS Code auto-updates to new versions, and collects usage data and crash report information. You may opt out of these defaults by disabling them as instructed below:

O Guia Completo do React e o seu Ecossistema


Você já até estudou um pouco sobre a biblioteca desenvolvida pelo Facebook mas quer consolidar os seus conhecimentos?

Então esse post é pra você. Continue lendo para aprender:

  • O porquê do React
  • Como começar uma aplicação com React
  • Pra quê serve o JSX
  • O que é Virtual DOM
  • Como funciona o lifecycle dos componentes React
  • A Era da Componentização
  • One-way data binding
  • Flux, Redux ou MobX
  • O que usar para criar testes unitários com React

Introdução

Para começar precisamos saber o que é o React. Para isso, nada melhor do que utilizar a definição de quem o criou, o próprio Facebook, que o define assim:

Uma biblioteca JavaScript declarativa, eficiente e flexível para criar interfaces visuais

Com isso, temos que:

  1. O React não é um framework, mas uma biblioteca (library).
  2. O React serve para criar interfaces visuais (UI).

Essas duas informações juntas criam a primeira grande confusão para quem está começando: se o React é apenas uma biblioteca e só serve para criar UI, como posso criar aplicações completas com ele?

E para resolver essa questão precisamos entender que quando a comunidade se refere ao React, o que na verdade ela está querendo dizer é o React e o seu ecossistema.
E esse ecossistema é formado por:

  • React
  • JSX
  • ES2015
  • Webpack
  • Flux/Redux
  • axios/fetch
  • Jest/Mocha

E com todos esses itens, que fazem parte do ecossistema do React, conseguimos afirmar que é possível sim criar aplicações completas usando o React.

JSX

Explicando de forma rápida, o JSX é uma extensão de sintaxe do JavaScript (daí o nome, JavaScript Syntax eXtension) que nos permite escrever HTML dentro do JavaScript.

Nos primórdios, o JSX era um dos grandes motivos das críticas e piadas em relação ao React. Em teoria estávamos voltamos no tempo ao misturar HTML com JavaScript.

Os críticos mais ferrenhos afirmavam que o JSX quebra um dos princípios básicos do desenvolvimento de software, que é o Separation of Concerns.
Na minha opinião, essa visão é errada por dois motivos:

  1. O React em si, a biblioteca e não o ecossistema, como já falei anteriormente, representa apenas a parte da view da sua aplicação. Portanto, por definição, ele tem apenas um concern: renderizar a UI. Então quais concerns estão sendo violados?
  2. E mesmo que o JSX violasse esse princípio, a área de tecnologia evolui (e muito) com o tempo. Se um dos princípios que nós sempre demos como verdade não fizer mais sentido para um determinado cenário, deveremos nos forçar a seguir esse princípio mesmo assim?

Independente das minhas opiniões pessoais, com o tempo a comunidade percebeu que o JSX foi uma decisão acertada e que acabou se tornando um dos grandes alicerces do sucesso do React.

Componentes

Como foi dito anteriormente, o React tem como função principal auxiliar na criação da UI. Só deixei um detalhe importante de fora: o React usa componentes, e apenas componentes, para que que seja possível aumentar o máximo do reuso na sua aplicação.

Para exemplificar, vamos ver um pouco de código para entender como é um componente React:

import React from react;
export default function Button() {
return (
<button
onClick={() => alert(Clicked)}
>Click me</button>
);
}
view rawbutton.js hosted with ❤ by GitHub

A função acima (sim, componentes React podem ser simplesmente funções em JavaScript) gera um botão que mostra um alert para o usuário ao ser clicado.

Se precisarmos de outro botão como esse, basta reaproveitá-lo sem a necessidade de adicionar mais código na aplicação. Lembrando que mais código é sinônimo de mais trabalho, mais testes unitários e mais potenciais bugs inseridos.

E se a necessidade for um botão parecido com esse, basta editarmos passando alguns parâmetros (vamos falar mais sobre eles na próxima seção) e transformá-lo no que precisamos.

Se houver algum bug no comportamento, ou mesmo no layout do botão, sabemos exatamente onde devemos mexer no código para fazer o conserto rápido.

Em resumo, os componentes em React nos deixam mais produtivos. Com eles temos um reaproveitamento de código maior e uma menor probabilidade de novos bugs serem introduzidos na aplicação.

Props

Em todos os tipos de paradigmas no desenvolvimento de software, passar parâmetros é extremamente comum. Com os componentes do React isso não poderia ser diferente. A diferença é que no React, usamos os props (abreviação para properties).

A ideia é simples.

O componente abaixo, mostra para o usuário um Hello World:

import React from react;
export default function HelloWorld() {
return (
<h1>Hello World</h1>
);
}
view rawhello-world.js hosted with ❤ by GitHub

Imaginando que precisamos mudar a mensagem ‘World’ para alguma outra que for enviada dinamicamente, podemos reescrever esse componente usando as propsdessa forma:

import React from react;
export default function HelloWithProps(props) {
return (
<h1>Hello {props.name}</h1>
);
}
view rawhello-with-props.js hosted with ❤ by GitHub

E com isso feito, podemos chamar esse componente dentro de outros assim:

import React from react;
import HelloWithProps from ./hello-with-props;
export default function App() {
return (
<div>
<HelloWithProps name=World />
<HelloWithProps name=Brazil />
</div>
);
}
view rawapp.js hosted with ❤ by GitHub

Além disso, podemos fazer uma validação das props que são passadas no componente para evitar bugs desnecessários e facilitar no desenvolvimento da aplicação usando os PropTypes:

import React from react;
import PropTypes from prop-types;
export default function HelloWithProps(props) {
return (
<h1>Hello {props.name}</h1>
);
}
HelloWithProps.propTypes = {
name: PropTypes.string.isRequired,
};
view rawprop-types.js hosted with ❤ by GitHub

Agora, informamos explicitamente ao React para apenas aceitar a prop quando ela for uma string. Se qualquer outra coisa for passada para esse componente, a aplicação irá falhar e receberemos uma mensagem de erro nos avisando o porquê.

Para ler mais sobre os PropTypes, entre na documentação completa na própria página do React.

Outras possibilidades para lidar com os PropTypes são: o Flow e o TypeScript.

State

O estado (ou state) da sua aplicação, pode ser definido como: o lugar onde os dados vem e se transformam ao longo do tempo.

Dito isso, os componentes React podem ser divididos em duas categorias:Presentational e Container. Outra nomenclatura usada na comunidade para esses dois é: Stateless (sem estado) e Stateful (com estado).

Os componentes do tipo Presentational, se importam somente com a apresentação dos dados, portanto não tem estado (stateless).
Eles podem ser escritos como uma simples função:

import React from react;
export default function Presentational() {
return (
<h1>Hello World</h1>
);
}
view rawpresentational.js hosted with ❤ by GitHub

O ideal é escrever o máximo possível de componentes dessa categoria. Eles são mais fáceis de desenvolver, manter e testar.

Já os componentes do tipo Container, além da apresentação dos dados, tem que lidar também com algum tipo de lógica, ou transformação de dados. Por isso necessitam de estado (stateful).
Esses componentes não podem ser escritos como uma função, eles obrigatoriamente devem ser uma classe:

import React from react;
export default class Container extends React.Component {
constructor(props) {
super(props);
this.state = { name: World };
}
render() {
return (
<h1>Hello {this.state.name}</h1>
);
}
}
view rawcontainer.js hosted with ❤ by GitHub

Os dois exemplos mostrados acima tem exatamente o mesmo resultado final. A única diferença é que o primeiro deles não usa o state do React, enquanto que o segundo usa.

Podemos ainda complicar um pouco mais o segundo exemplo, para demonstrar como é possível alterar o estado do seu componente React:

import React from react;
export default class Container extends React.Component {
constructor(props) {
super(props);
this.state = { name: World };
}
change(event) {
this.setState({ name: event.target.value });
}
render() {
return (
<div>
<input value={this.state.name} onChange={(e) => this.change(e)} />
<p>Hello {this.state.name}!</p>
</div>
);
}
}
view rawcontainer.js hosted with ❤ by GitHub

Em cada mudança que ocorrer no input (linha 16), um evento é disparado na função change. A função change por sua vez altera o estado do componente, usando a função setState, que é nativa do React.

Toda vez que o estado for alterado, o React automaticamente invoca de novo a função render, que irá renderizar a UI com os novos dados inputados pelo usuário.

One-way data binding

É bem mais fácil falar dos benefícios do one-way data binding (ou one-way data flow), demonstrando o fracasso do seu “concorrente”, o two-way data binding.

Angular.js ganhou bastantes usuários, principalmente entre 2012 e 2015, e um dos principais motivos para isso, era justamente o two-way data binding.

https://docs.angularjs.org/guide/databinding

O *two-way data binding *funciona assim: se uma mudança acontece na view, ela é refletida automaticamente no model, e vice-versa.

No começo, o two-way data binding parecia uma excelente ideia. Com o tempo, após inúmeros projetos construídos usando essa tecnologia, ela se mostrou extremamente nociva principalmente por dois motivos:

  1. Performance
  2. Manter aplicações grandes se mostrou extremamente difícil

A própria equipe do Angular resolveu limitar essa funcionalidade nas novas versões do* framework*.

O React porém, percebeu essa falha desde o início e estimula apenas o uso do one-way data binding.

Não existe um mecanismo no React que permita com que o HTML altere os dados do componente. E nem vice-versa. Essa mudança é sempre feita de forma explícita pelo desenvolvedor. Lembrando que explícito é muito melhor, em termos de desenvolvimento, manutenção e testes, do que implícito.

Um exemplo simples de one-way data binding em ação no React pode ser visto no componente abaixo:

import React from react;
export default class App extends React.Component {
constructor(props) {
super(props);
this.state = { count: 0 };
}
increment() {
this.setState({ count: this.state.count + 1 });
}
render() {
return (
<div>
<h1>{this.state.count}</h1>
<button onClick={this.increment.bind(this)}>+</button>
</div>
);
}
}
view rawcounter.js hosted with ❤ by GitHub

Se estivéssemos no mundo two-way data binding do Angular.js, o model e a viewestariam conectados implicitamente e ambos mudariam juntos.

Porém, com o one-way data binding do React, precisamos explicitamente invocar a função setState para que o estado seja alterado. Dessa forma temos muito mais previsibilidade e segurança da nossa aplicação.
Isso fica muito evidente conforme a aplicação cresce.

Lifecycle

Para que seja possível o desenvolvimento de componentes mais complexos, alguns métodos foram adicionados na API dos componentes React.
Eles fazem parte do Component Lifecycle (ciclo de vida dos componentes).

Com esses métodos, os desenvolvedores podem saber, por exemplo, quando um componente vai ser criado, destruído, atualizado, etc.

São esses os métodos de lifecycle dos componentes:

  • componentWillMount, executado logo antes do primeiro render. Não é muito usado, geralmente faz mais sentido simplesmente usar o próprio construtor da classe.
  • componentDidMount, executado logo após o primeiro render. É provavelmente o método mais usado. Alguns exemplos de casos de uso são: chamadas AJAX, manipulação do DOM, início de setTimeouts e setIntervals, etc.
  • componentWillReceiveProps, executado quando as props que o componente recebe são atualizadas. Geralmente é usado quando os componentes precisam reagir aos eventos externos.
  • componentWillUpdate, é igual ao componentWillMount, só que ele executa logo antes da atualização de um componente.
  • componentDidUpdate, é igual ao componentDidMount, só que ele executa logo depois da atualização de um componente.
  • componentWillUnmount, executado quando o ciclo de vida de um componente termina e ele vai ser removido do DOM. É muito usado para remover setTimeouts e setIntervals que foram adicionados.
  • shouldComponentUpdate, deve retornar true/false. Esse valor vai dizer que se o componente deve ser atualizado ou não, com base em certos parâmetros. Geralmente é usado para resolver questões de performance.

Um exemplo simples de uso dos métodos de lifecycle, seria o contador de segundos abaixo:

import React from react;
export default class Timer extends React.Component {
constructor(props) {
super(props);
this.state = { elapsed: 0 };
this.tick = this.tick.bind(this);
}
componentDidMount() {
this.timer = setInterval(this.tick, 1000);
}
componentWillUnmount() {
clearInterval(this.timer);
}
tick() {
this.setState({ elapsed: this.state.elapsed + 1 });
}
render() {
return <h1>{this.state.elapsed} seconds</h1>;
}
}
view rawtimer.js hosted with ❤ by GitHub

Assim que o componente é montado (componentDidMount), nós iniciamos osetInterval que a cada 1000ms invoca a função tick. E quando o componente for destruído (componentWillUnmount) removemos o setInterval para que a função ticknão continue sendo chamada desnecessariamente.

Virtual DOM

A manipulação do DOM está no centro do desenvolvimento front-end moderno. Fazemos isso basicamente todos os dias.
Só tem dois problemas com isso:

  1. Essa manipulação direta do DOM é mais lenta do que a maioria das operações feitas pelo JavaScript
  2. A maioria dos frameworks JavaScript alteram muito mais o DOM do que deveriam

Sabendo disso, o Facebook criou o Virtual DOM.
Ele funciona da seguinte forma: no React, uma cópia de todos os nodes do DOM são replicados em código JavaScript. Ao invés de fazer alterações diretamente no DOM (que são lentas) elas são feitas no Virtual DOM (rápidas). E somente quando realmente necessário, essas alterações são repassadas para o DOM original.

Esse é um dos principais motivos para os benchmarks de performance excelentes que o React tem.

Agora que já entendemos as partes fundamentais do React, precisamos entender também o seu ecossistema.


create-react-app

Nos primeiros anos do React, uma das principais críticas era de que iniciar uma aplicação era muito mais complicado do que deveria ser, o que acabava excluindo diversos iniciantes.

Antes de sequer começar a primeira linha de código em React, os desenvolvedores precisavam aprender no mínimo: Webpack e ES2015.

Hoje isso não é mais um problema, a equipe do Facebook vem trabalhando diariamente no projeto create-react-app.

Agora, com apenas 4 simples comandos, sem ter que criar e editar nenhuma configuração, temos um arcabouço completo para começar a desenvolver aplicações em React:

npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start

CSS-in-JS

Todas as boas práticas ao se escrever CSS apontavam para um mesmo caminho por anos: escrever CSS o mais desacoplado possível do JavaScript e do HTML, usando nomes bem descritivos para as classes.

O problema dessa abordagem é que ela não resolve o maior defeito do CSS: tudo o que você cria é global. Cada vez que você cria uma nova classe CSS ela é, por definição, global. Isso gera diversos problemas na manutenção, principalmente em aplicações maiores.

Com o grande sucesso da componentização no React, a forma de se escrever CSS vem mudando drasticamente.

A primeira revolução veio com o CSS Modules.

import React from react;
import styles from ./styles.css;
const Main = () => (
<button
onClick={() => alert(Clicked)}
className={styles.button}
>Click me</button>
);
export default Main;
view rawmain.js hosted with ❤ by GitHub

A ideia é simples: escrever o mesmo CSS de sempre, só com uma diferença: esse CSS só vai valer para aquele componente. Ou seja, será um módulo (daí o nome, CSS Modules).

Um exemplo simples de uso do CSS Modules:

.button {
background-color: blue;
border: none;
color: white;
padding: 5px 10px;
}
view rawstyles.css hosted with ❤ by GitHub

E o arquivo de estilos que só valerá para o componente acima:

A segunda revolução veio com o styled-components.

Nesse, o próprio componente já teria seus estilos escritos em JavaScript, sem que nenhum arquivo CSS seja sequer criado.

Uma das vantagens do styled-components, é que o code-splitting fica muito mais fácil de ser feito, e assim como o CSS Modules, não existe CSS global. A desvantagem é que você não escreve o CSS padrão que muitos já estão acostumados, o que pode não ser muito intuitivo.

Um exemplo simples:

const Button = styled.a`
display: inline-block;
border-radius: 3px;
padding: 0.5rem 0;
margin: 0.5rem 1rem;
width: 11rem;
background: transparent;
color: white;
border: 2px solid white;
${props => props.primary && css`
background: white;
color: palevioletred;
`}
`
view rawbutton.js hosted with ❤ by GitHub

Bundlers

Resolver dependências no front-end, apesar de ser uma questão comum, sempre foi extremamente problemático.

Na maioria dos projetos temos que lidar, no mínimo, com essas questões:

  • A concatenação e minificação do JavaScript (ou TypeScript, ES2015, CoffeScript, etc) e do CSS (ou Sass, Less, Stylus, etc)
  • Inclusão de Imagens
  • Adição de Fontes

Dessa necessidade frequente das aplicações* front-end*, surgiram os module bundlers. E no mundo React, o bundler mais usado pela comunidade é o Webpack.

Além de resolver todos os problemas acima (imagens, fontes e a minificação/concatenação de JavaScript e CSS), o Webpack também consegue prover:

Além de outras features também muito interessantes.

State containers

Para aplicações mais complexas usar apenas o setState nativo do React pode não ser o suficiente para controlar toda a lógica da aplicação.

Existem diversos gerenciadores de estado feitos exclusivamente para lidar com esse problema, dentre eles: FluxMobXReflux e o mais famoso deles, o Redux.

Dito isso, **toda vez que tivermos que tomar uma decisão de se adicionar uma nova biblioteca no projeto, temos que pesar o custo/benefício dessa decisão. **E para a grande maioria das aplicações, que não são complexas o bastante, nenhuma das opções acima (inclusive o Redux) são necessárias.

Me preocupa ver na comunidade, diversos iniciantes começando a aprender o Redux antes mesmo de entender bem o próprio React. Ou mesmo criando projetos já com o Redux, sem antes ter visto se há de fato uma necessidade.

O próprio criador do Redux já falou sobre isso:

Testes

Outro ponto crucial para o desenvolvimento de aplicações web é o uso de testes unitários. As garantias de que os testes nos dão são consideráveis. Podemos refatorar, encontrar e evitar novos bugs, e até mesmo para escrever código a partir dos testes (TDD).

No mundo React, a principal ferramenta para escrever testes unitários é o Jest, que é mais um open source do Facebook.

O Jest tem três vantagens principais em relação aos concorrentes:

  1. É extremamente fácil de configurar
  2. Ele vem com tudo o que você precisa para testar: o runner, as assertions, o report de coverage, etc. Não é mais necessário instalar diversas bibliotecas diferentes para poder escrever testes unitários.
  3. Snapshots

Esse último é tão interessante que vale a pena se aprofundar um pouco mais.
A ideia das Snapshots é simples: o Jest tira uma “foto” do seu componente, e se algo mudar o seu teste vai quebrar e te avisar dessa mudança, mostrando exatamente como o componente era e como ele ficou.

E isso tudo com pouquíssimas linhas de código:

import React from react;
import Link from ../Link.react;
import renderer from react-test-renderer;
it(renders correctly, () => {
const tree = renderer.create(
<Link page=http://www.facebook.com>Facebook</Link>
).toJSON();
expect(tree).toMatchSnapshot();
});
view rawtest.js hosted with ❤ by GitHub

Conclusão

E pra recapitular, nesse post aprendemos as partes mais centrais do React como: JSX, Virtual DOM, Lifecycle, Componentização, One-way data binding, etc.

E além disso, conhecemos também os principais atores que fazem parte do ecossistema do React, dentre eles: Webpack, create-react-app, Jest, CSS Modules, etc.

Mas se mesmo assim ficou alguma dúvida, basta adicionar a pergunta nos comentários abaixo 🙂


**Se você gostou do post não se esqueça de dar um ❤ aqui embaixo!E se quiser receber de antemão mais posts como esse, assine nossa newsletter.**

Seja um apoiador, doe BitCoins: 1BGVKwjwQxkr3w1Md2X8WHAsyRjDjyJiPZ

JSCasts

É difícil encontrar conteúdo bom e atualizado em português. Com isso em mente criamos o JSCasts, onde você vai se manter em dia com o JavaScript e todo o seu ecossistema de forma fácil e interativa.

Cursos:

Tutorial Ionic – Meu primeiro app


Introdução

Após publicar uma breve introdução do Ionic Framework, vamos agora tentar construir uma app que consiga abordar o uso de componentes nativos de um celular assim como o build para as determinadas plataformas.

Para isso, ao decorrer deste tutorial, vamos construir uma app bastante simples que utiliza a posição do usuário para exibir os dados do tempo na tela.

O que é necessário?

  1. NodeJS
  2. NPM

Após instalar os 2, vamos instalar o ionic e o cordova como módulos globais.

npm install -g ionic cordova

Criando o projeto

Para criar a estrutura inicial do projeto, vamos utilizar o gerador do Ionic CLI. Como o app é bastante simples, vamos utilizar o gerador blank do ionic.

ionic start weather blank

estrutura de páginas do Ionic

Podemos ver então a estrutura de pastas inicial do projeto. Inicialmente vamos mexer somente no conteúdo da pasta www que é onde se encontra nosso projecto html, css e js.

APIS e Plugins utilizados

Para fazer a captura dos dados meteorológicos vamos utilizar uma API gratuita chamada Forecast for Developers. Para fazer a captura dos dados temos que utilizar um plugin do Cordova de Geolocalização. É importante dizer que não é recomendável utilizar o navigator.geolocation nativo pois ele irá pedir permissão para o usuário com frequência e irá mostrar uma mensagem não amigável para isso como a imagem abaixo ilustra.

Diálogo de permissão de localização via html5

Para instalar o plugin de geolocalização do Cordova, basta rodarmos o comando abaixo na pasta do projeto.

cordova plugin add org.apache.cordova.geolocation

Após instalado o plugin do cordova, vamos instalar uma lib que tem implementado a comunicação com alguns plugins do Cordova de uma forma mais amigável para o AngularJS que é o ngCordova.

Para instalar o ngCordova basta rodar

bower install ngCordova

E importar no arquivo www/index.html.

<script src="lib/ngCordova/dist/ng-cordova.js"></script> 
<script src="cordova.js"></script> 

Após feito isso, devemos avisar para o AngularJS que nosso projeto depende deste módulo. Esta definição está no arquivo www/js/app.js

(function() {
    angular.module('weather', ['ionic', 'ngCordova'])
        .run(function($ionicPlatform) {
            $ionicPlatform.ready(function() {
                // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard
                // for form inputs)
                if (window.cordova && window.cordova.plugins.Keyboard) {
                    cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
                }
                if (window.StatusBar) {
                    StatusBar.styleDefault();
                }
            });
        });
})();

Desse momento em diante temos acesso a todos os módulos do ngCordova.

Organização

Como a App é bastante simples, não vamos fragmentar a implementação em diversos arquivos. Vamos focar em construir apenas utilizando o app.js. Vamos então construir 2 componentes no AngularJS, o serviço Weather para se comunicar com a API e o controller WeatherCtrl para fazer a ponte entre a nossa view e a api.

(function() {
    angular.module('weather', ['ionic', 'ngCordova'])
        .run(function($ionicPlatform) {
            $ionicPlatform.ready(function() {
                // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard
                // for form inputs)
                if (window.cordova && window.cordova.plugins.Keyboard) {
                    cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
                }
                if (window.StatusBar) {
                    StatusBar.styleDefault();
                }
            });
        })
        .factory('Weather', function($http) {

        })
        .controller('WeatherCtrl', function($scope, Weather) {

        });
})();

Após feito isso, devemos fazer o bind entre o WeatherCtrl e o nosso HTML.

<body ng-app="weather" ng-controller="WeatherCtrl as weatherCtrl">
    <ion-pane>
        <ion-header-bar class="bar-stable">
            <h1 class="title">Weather</h1>
        </ion-header-bar>
        <ion-content>
            
        </ion-content>
    </ion-pane>
</body>

Feito isso, devemos então implementar o acesso aos dados da API através de uma posição geográfica.

.factory('Weather', function($q, $http) {
            var deferred = $q.defer();

            function getCurrentWeather(lat, lng) {
                var url = 'https://api.forecast.io/forecast/SUA_CHAVE_DE_API/' + lat +',' + lng + '?callback=JSON_CALLBACK';
                $http.jsonp(url)
                    .success(deferred.resolve)
                    .error(deferred.reject);

                return deferred.promise;
            }

            return {
                getCurrentWeather: getCurrentWeather
            };
        })

O serviço retorna uma promise que é o retorno da chamada JSONP para a API que iremos capturar no controller após acessarmos a localização do dispositivo.

Com o serviço pronto, vamos então fazer a chamada ao GPS no controller e com a posição, vamos capturar os dados meteorológicos.

.controller('WeatherCtrl', function($scope, $cordovaGeolocation, Weather) {
            $scope.loading = true;

            $scope.toCelsius = function(temperature) {
                return ((temperature - 32) / 1.8).toFixed(1);
            };

            $cordovaGeolocation
                .getCurrentPosition({
                    timeout: 10000,
                    enableHighAccuracy: false
                })
                .then(function(position) {
                    var lat = position.coords.latitude;
                    var long = position.coords.longitude;

                    Weather.getCurrentWeather(lat, long).then(function(data) {
                        $scope.weatherInfo = data;
                        $scope.loading = false;
                    }, function(error) {
                        //TODO Display error message
                    });
                }, function(err) {
                    //TODO Display error message
                });
        });

Se vocês repararem, eu adicionei umas variáveis ao escopo para controlar se está carregando dados ou não e para converter de Fahrenheit para Celsius que usaremos posteriormente no nosso HTML.

Com o controller preparado vamos então preparar o nosso HTML para mostrar uma imagem de carregamento enquanto não demos os dados e posteriormente mostrar a temperatura e a sensação térmica em celsius.

<body ng-app="weather" ng-controller="WeatherCtrl as weatherCtrl">
    <ion-pane>
        <ion-header-bar class="bar-stable">
            <h1 class="title">Weather</h1>
        </ion-header-bar>
        <ion-content class="text-center">
            <div ng-show="loading">
                Carregando informações...
            </div>
            <div ng-hide="loading">
                <p>
                    Temperatura: {{toCelsius(weatherInfo.currently.temperature)}}º
                </p>
                <p>
                    Sensação térmica: {{toCelsius(weatherInfo.currently.apparentTemperature)}}º
                </p>
            </div>
        </ion-content>
    </ion-pane>
</body>

Para visualizar o resultado podemos rodar o projeto no navegador utilizando o comando

ionic serve

Gerando as builds para o celular

Para gerar as os pacotes de App para celular basta rodarmos alguns comandos no Ionic CLI. É importante ressaltar que para criar o projeto iOS é necessário possuir um computador OSX.

Adicionando as plataformas

Para adicionarmos as plataformas em que vamos compilar nossa app bastar rodar o comando ionic platform add PLATFORM passando a plataforma desejada. Para efeitos de teste, vamos utilizar apenas o Android.

ionic platform add android

Após rodar esse comando vamos ver que o Ionic está criando um projeto Android dentro da pasta platforms.

Criação do projeto Android

A partir daí não precisamos fazer mais nada! Basta rodar a app em seu aparelho ou emulador através do comando

ionic run android

Este comando irá fazer o build e enviar para o celular que estiver conectado ou emulador que estiver aberto.

Para quem quiser, o projeto está disponível no Github

A importância de desenvolver considerando off-line first


Você está em casa à noite e resolve baixar um jogo no seu smartphone. Depois de algumas horas jogando, é hora de ir dormir porque no dia seguinte você tem um voo para pegar. Logo após a decolagem você resolve passar mais uma fase daquele joguinho que instalou. Ao abrir o aplicativo, você se depara com a necessidade de conexão com a internet para jogar (e muitas vezes até para abrir o jogo).

Isso não é “privilégio” apenas de jogos e acontece com frequência porque boa parte das aplicações dependem da conexão à internet para funcionar (mesmo aquelas que foram baixadas previamente). Muitas vezes isso é desnecessário pois a aplicação que envia pequenos pacotes de dados poderia acumular esses pacotes caso estivesse sem uma conexão disponível no momento.

Foi com esse intuito, de promover a criação de aplicações que funcionem também off-line, que estão surgindo iniciativas para auxiliar o desenvolvimento de apps que sobrevivam quando você estiver em um túnel, no avião ou no meio de uma trilha na floresta. Uma delas é a Off-line first, que defende que sua aplicação deve estar pronta para cenários sem acesso a internet. Essas iniciativas fazem uso de recursos e documentação que já estamos acostumados a acompanhar, mas nem sempre com esse viés de garantir o funcionamento sem internet.

Um dos pontos fundamentais para o funcionamento de aplicações Web rodarem off-line é garantir que seja possível acessa-las em cache. Pode parecer desnecessário e redundante falar isso em pleno 2015, mas ainda existem aplicações que não armazenam dados em cache.

Dentro da documentação do HTML5 existe um tópico dedicado exclusivamente para aplicações Web off-line. Para ilustrar essa documentação, o próprio W3C mostra um exemplo simples de uma aplicação de um relógio, e como adicionar o manifest de forma adequada. O exemplo desse relógio está disponível na página do WHATWG.

Além disso, temos em nosso favor a Web Storage API, que nos possibilita armazenar dados da aplicação no client side.

A preocupação em garantir o funcionamento de aplicações off-line não é está apenas dentro das recomendações do W3C. O Google tem uma área interessante sobre a criação de apps off-line first. O documento começa com algumas dicas fundamentais para a criação do aplicativos:

  • Os arquivos do aplicativo – JavaScript, CSS e fontes, além de outros recursos necessários (como imagens) já foram baixados.
  • Seu aplicativo pode salvar e sincronizar (de forma opcional) pequenas quantidades de dados.
  • Seu aplicativo pode detectar mudanças na conectividade.

Mesmo que essas dicas sejam insuficientes, o Google recomenda seguir algumas regras para isso:

  • Use dados locais sempre que possível
  • Separe UI (User Interface) dos dados da sua aplicação
  • Suponha que seu aplicativo pode ser fechado a qualquer momento.
  • Teste seu aplicativo cuidadosamente.

Mozilla também tem documentação muito interessante sobre a construção de aplicações desconectadas da internet. Lá também estão algumas recomendações para o desenvolvimento de uma boa aplicação off-line. Basicamente a documentação recomenda o seguinte:

  • A aplicação deve detectar o estado “_off-line_”

    Já existem APIs que determinam o status de conexão do usuário, sem a necessidade de HTTP request.

  • Armazenamento de “_data and assets_” off-line

    Garanta que o armazenamento de dados possa ser feito no dispositivo do usuário.

  • Salve os status da aplicação periodicamente

    Durante o uso da aplicação, considere salvar periodicamente o status no dispositivo do usuário.

  • Sincronize com o servidor

    A aplicação deve enviar periodicamente os dados para o servidor. Quando não conseguir, ela pode fazer o armazenamento no dispositivo do usuário e enviar quando possível. Considere construir uma solução para organizar a fila de pacotes quando a conectividade cair.

Mesmo sabendo que a conectividade vem aumentando e melhorando de forma exponencial, vale a pena planejar o uso da sua aplicação em um cenário sem internet. Em um país com proporções continentais como o Brasil e com um percentual de 84% da população com telefone celular (dados do Cetic.br de 2014), é fundamental que a aplicação não se limite apenas a momentos em que o usuário esteja conectado (claro que isso não é possível em todas as aplicações). A Web móvel é uma realidade e a mobilidade nos deixa sujeitos a oscilações de conectividade. E nossas aplicações devem estar prontas para isso.

Boas referências para estudo: