Criando seu próprio bloco Gutenberg: Parte 2

No post anterior vimos como trabalhar com blocos customizados, conceitos básicos de como registrar nosso bloco como um plugin e criar um markup básico com JavaScript. Nesse post vamos evoluir o nosso bloco todo código está disponível no Github. Primeiro passo vamos ver como os blocos trabalham com estilo externo.

Carregando estilo externo

Primeiro passo será criar nossos arquivos CSS, um arquivo para o front-end de nossa aplicação e o segundo para nosso editor.

style.css(front-end e editor):

.wp-block-fellyph-tutorial-02 {
  background: linear-gradient(45deg, #12c2e9, #c471ed, #f64f59);
  padding: 2em;
  color: white;
  font-size: 20px;
  box-sizing: border-box;
  transform: rotate3d(0, 0, 0, 0);
  transition: all 200ms ease-out;
  box-shadow: 3px 3px 3px #666;
  text-align: center;
}

.wp-block-fellyph-tutorial-02:hover {
  transform: rotate3d(1, 1, 1, -4deg);
}

editor-style.css(somente editor)

.wp-block-fellyph-tutorial-02 {
  background: #12c2e9;
  border: 3px solid #666;
  box-shadow: 0 0 0 #666;
}

.wp-block-fellyph-tutorial-02:hover {
  transform: rotate3d(0, 0, 0, 0);
}

Temos acima os dois códigos que iremos carregar em nossa aplicação, dois pontos importantes, um o nome da classe ela sempre irá iniciar com ‘wp-block-‘ mais o nome que registramos o nosso bloco, nesse caso o ‘fellyph/tutorial-02‘ irá se transformar em fellyph-tutorial-02, assim temos a classe wp-block-fellyph-tutorial-02.

Segundo ponto, quando trabalhamos com a função register_block_type ela espera 4 parâmetros:

  • style
  • script
  • editor_style
  • editor_script

As propriedades script e style representam os arquivos que serão carregados no editor e front-end da aplicação, enquanto editor_style e editor_script serão carregados apenas no editor do WordPress. Nesse caso o estilo no arquivo editor-style irá sobrescrever o estilo do arquivo style.css. Para ficar mais claro vamos ver o print do resultado desses dois estilos:

Estilo aplicado em nosso front-end
Estilo aplicado em nosso editor

Temos um spoiler de como ficará esse nosso bloco, mas como podemos observar, o bloco no editor herda todas as propriedades do bloco do front-end, por exemplo, alinhamento, padding e a cor da fonte, essas características foram de no arquivo style.css.

index.php

Agora vamos dar uma olhada em nosso arquivo principal:

<?php

/**
 * Plugin Name: Gutenberg tutorial
 * Plugin URI: https://github.com/fellyph/Gutenberg-tutorials
 * Description: Este tutorial ensina como criar um bloco gutenberg https://blog.fellyph.com.br/wordpress-2/criando-seu-proprio-bloco-gutenberg/.
 * Version: 1.2
 * Author: fellyph
 */

defined( 'ABSPATH' ) || exit;

/**
 * 1 - Criando nosso primeiro bloco: Parte 02
 *    - Carregando arquivo externo para nosso estilo
 */
function meu_primeiro_bloco_gutenberg_parte_02 () {

	if ( ! function_exists( 'register_block_type' ) ) {
		// Checamos se temos suporte a função register_block_type antes de tudo.
		return;
	}

	wp_register_script(
		'tutorial-02',
		plugins_url( 'script.js', __FILE__ ),
		array( 'wp-blocks', 'wp-element' ),
		filemtime( plugin_dir_path( __FILE__ ) . 'script.js' )
	);

	wp_register_style(
		'style-editor',
		plugins_url( 'editor-style.css', __FILE__ ),
		array('wp-edit-blocks'),
		filemtime( plugin_dir_path( __FILE__ ) . 'editor-style.css' )
	);

	wp_register_style(
		'style-frontend',
		plugins_url( 'style.css', __FILE__ ),
		filemtime( plugin_dir_path( __FILE__ ) . 'style.css' )
	);

	register_block_type( 'fellyph/tutorial-02', array(
		'style' => 'style-frontend',
		'editor_script' => 'tutorial-02',
		'editor_style' => 'style-editor'
	) );
}

add_action( 'init', 'meu_primeiro_bloco_gutenberg_parte_02' );

Não vamos abordar todas as partes desse código caso não tenha visto a primeira parte dessa séria aqui está o link: https://blog.fellyph.com.br/wordpress-2/criando-seu-proprio-bloco-gutenberg.

Comparado ao tutorial anterior, acrescentamos duas funções wp_register_style, uma para estilo geral e outra para o estilo do nosso editor e por fim passamos como parâmetro na função register_block_type.

script.js

Em nosso script agora temos o seguinte código:

( function( blocks, element ) {
	var el = element.createElement;


	blocks.registerBlockType( 'fellyph/tutorial-02', {
		title: 'Primeiro bloco Gutenberg: Parte 02',
		icon: 'smiley',
    category: 'layout',
  
		edit: function(props) {
			return el(
				'p',
				{ className: props.className },
				'Este conteúdo será exibido no editor.'
			);
		},
		save: function(props) {
			return el(
				'p',
				{ className: props.className },
				'Este conteúdo será exibido para o usuário final.'
			);
		},
	} );
}(
	window.wp.blocks,
	window.wp.element
) );

Comparado a versão anterior passamos nas funções dentro das propriedades edit e save uma propriedade chamada props, ela contém informações referente ao nosso bloco e uma delas é o nome dessa classe, não obrigatório passar o className dinamicamente poderíamos passar um valor estático, mas para facilitar a manutenção e evitar conflitos com outros blocos utilizamos o nome de classe dinamicamente.

Uma observação sobre a propriedade “icon” caso queira saber os ícones disponíveis dentro do WordPress, só acessar o link: https://developer.wordpress.org/resource/dashicons/#smiley lá você irá encontrar uma série de ícones separados por categoria.

Na página de dashicons você pode conferir o id para cada ícone

No meu caso eu selecionei o ícone smiley, como podemos ver na imagem abaixo, quando clico no ícone temos seu id e como utiliza-lo em nosso CSS ou HTML, mas eu só irei precisar do id ‘dashincons-smiley’ em nosso script usamos ‘dashicons-‘ apenas smiley.

A nível de curiosidade eu alterei a função edit para ver quais são os valores passados dentro de props(você não precisa implementar isso).

edit: function(props) {
			var test = 'Este conteúdo será exibido no editor. / ';
			for(var key in props) {
				 test += key + " : " + props[key] + ' / ';
			}

			return el(
				'p',
				{ className: props.className },
				test
			);
		},

O resultado foi o seguinte:

Dentro do objeto props temos as seguintes propriedades e funções:

  • name
  • isSelected
  • attributes
  • setAttributes (function)
  • insertBlocksAfter (function)
  • onReplace (function)
  • mergeBlocks (function)
  • clientId
  • isSelectionEnabled
  • toggleSelection (function)
  • className

Para a estilização de nosso bloco poderíamos trabalhar com atributos dinâmicos, mas esse será assunto para um próximo post. Caso queira saber mais sobre como trabalhar com estilo em blocos customizados só deixar um comentário.

O código desse tutorial você irá encontrar na branch(tutorais/gutenberg-02) do repositório: https://github.com/fellyph/Gutenberg-tutorials/tree/tutoriais/gutenberg-02

Criando seu próprio bloco Gutenberg

Continuando a série sobre o Gutenberg nesse post vamos criar o nosso primeiro bloco Gutenberg, para esse exercício vamos nos basear no repositório oficial do WordPress, lá vamos encontrar uma série de exemplos de como trabalhar com blocos Gutenberg.

No desenvolvimento de blocos temos a possibilidade de criar blocos com EcmaScript 5 e ESNext. Neste tutorial vamos abordar os exemplos com ES5.

Escrevendo o primeiro bloco

Vamos partir do principio mais básico, exibir um bloco estático HTML. Essa função pode ser útil caso desejamos criar uma bloco de assinatura ou contato por exemplo. Nos posts seguintes vamos incrementando essa solução.

Para esse bloco temos dois conceitos importantes, o primeiro ele será adicionado como um plugin é uma técnica recomendada pela documentação, o segundo ponto toda o conteúdo HTML será definido por uma JavaScript. Então com essas premissas vamos ter dois arquivos base em nosso exemplo, o PHP(index.php) que irá inicializar nosso plugin e o Script(primeiro-bloco.js) responsável pelo conteúdo.

index.php

No index.php vamos gerenciar os passos necessários do nosso plugin que irá criar o nosso bloco Gutenberg, nele temos uma atenção especial para duas funções register_block_type e wp_register_script. 

Register_block_type será responsável por registrar o nosso dentro do WordPress como parâmentro ele espera, quais serão os scripts e estilos necessários para executar esse bloco, tanto dentro de editor como para o usuário final no front-end de nossa aplicação.

Wp_register_script será responsável por a tarefa de carregar o script do nosso bloco para o WordPress, assim o WordPress sabe a hora exata de carregar o script e qual serão suas dependências de script dentro da aplicação. Para ficar mais claro vamos ao nosso exemplo:

<?php

/**
 * Plugin Name: Gutenberg tutorial
 * Plugin URI: https://github.com/fellyph/Gutenberg-tutorials
 * Description: Este tutorial ensina como criar um bloco Gutenberg https://blog.fellyph.com.br/wordpress-2/criando-seu-proprio-bloco-gutenberg/.
 * Version: 1.0
 * Author: fellyph
 */

defined( 'ABSPATH' ) || exit;

/**
 * 1 - Criando nosso primeiro bloco
 *    1.1 - precisamos registrar nosso script para ser adicionado na função register_block
 *    1.2 - registramos nosso block type passando nosso script
 */
function meu_primeiro_bloco_gutenberg () {

	if ( ! function_exists( 'register_block_type' ) ) {
		// Checamos se temos suporte a função register_block_type antes de tudo.
		return;
	}

	wp_register_script(
		'tutorial-gutenberg-01',
		plugins_url( 'primeiro-bloco.js', __FILE__ ),
		array( 'wp-blocks', 'wp-element' ),
		filemtime( plugin_dir_path( __FILE__ ) . 'primeiro-bloco.js' )
	);

	register_block_type( 'fellyph/tutorial-01', array(
		'editor_script' => 'tutorial-gutenberg-01',
	) );
}

add_action( 'init', 'meu_primeiro_bloco_gutenberg' );

Notem quando registramos nosso script temos duas dependências wp-blocks e wp-element são requisitos mínimos para trabalhar com blocos, para entender mais sobre essas duas dependências:

  • wp-blocks inclui registro de tipos de blocos e mêcanica como os itens são armazenados formulários e funções relacionadas para cada evento específico quando o bloco é salvo ou exibido em nosso front-end
  • wp-element inclui uma camada de abstração pada os blocos Gutenberg, trás a renderização desses elementos do nosso back-end para nosso front-end.

JavaScript do nosso bloco

/**
 * 1 - primeiro bloco Gutenberg com ES5
 */
( function( blocks, element ) {
	var el = element.createElement;

	// criando estilo para nosso editor
	var blockStyle = {
		backgroundColor: 'green',
		color: 'white',
    padding: '2em',
    border: '3px solid black'
	};

//criando estilo para nosso front-end
	var blockStyleFront = {
		backgroundColor: 'blue',
		color: 'white',
    padding: '2em',
    border: '3px solid black'
	};

	blocks.registerBlockType( 'fellyph/tutorial-01', {
		title: 'Primeiro bloco Gutenberg',
		icon: 'universal-access-alt',
    category: 'layout',
  
		edit: function() {
			return el(
				'p',
				{ style: blockStyle },
				'Este conteúdo será exibido no editor.'
			);
		},
		save: function() {
			return el(
				'p',
				{ style: blockStyleFront },
				'Este conteúdo será exibido para o usuário final.'
			);
		},
	} );
}(
	window.wp.blocks,
	window.wp.element
) );

Lendo nosso código fica evidente a importância de nossas dependências vamos agora passar por alguns pontos chaves. O código Javascript temos o uso de IIFE para garantir que iremos rodar nosso script quando tivemos acesso aos scripts carregados pelo WordPress que estarão disponíveis globalmente por window.wp.blocks e window.wp.element

Dentro de nossa função armazenamos a função createElement responsável por criar nosso markup em uma variável “el” e na sequência criamos dois objetos responsáveis pelo estilo do nosso bloco blockStyle e blockStyleFront.

Com a inicialização de nossas variáveis vamos agora utilizar o wp-blocks, será carregado como blocks dentro do nosso script, assim, chamamos a função blocks.registerBlockType responsável por criar nosso bloco nela passamos o id do nosso bloco ele precisa ser único para evitar conflitos dentro de nossa aplicação, título(title), ícone(icon), categoria(category), a função que será chamada no editor(edit) e a função que será salva no front-end de nossa aplicação(save).

Ativando nosso primeiro bloco Gutenberg

Com os nosso plugin/bloco Gutenberg pronto, chegou a hora de ativa-lo, primeiramente devemos armazenar os dois arquivos em uma pasta para fazer a instalação como plugin.

Adicionamos a pasta de nosso plugin em wp-content / plugins

No meu caso eu criei a pasta gutenberg-tutoriais mas pode ser qualquer nome para essa pasta. Após a adição da pasta em minha aplicação WordPress precisamos instalar o nosso plugin.

Se tudo ocorrer bem vamos visualizar nosso plugin em nosso dashboard. Agora vamos ativar e testar o nosso plugin

Como será exibido o nosso bloco

Nosso bloco ativado irá aparecer na categoria layout como definimos em nosso script e podemos ver as outras configurações como o título “primeiro bloco gutenberg”.

Quando adicionamos o bloco ele irá aparecer da seguinte forma:

Nosso bloco Gutenberg em nosso editor.

Salvando o nosso bloco o resultado será o seguinte:

Notem que as cores dos nossos blocos mudam de uma para outros isso foi adicionado de forma proposital. Podemos adicionar markups e estilos diferentes para o bloco que será exibido no editor e no front-end de nossa aplicação.

Fechamos por aqui nosso primeiro post, vamos evoluindo nossos exercícios a partir desse ponto. Para acompanhar os exercícios só seguir o repositório no github: https://github.com/fellyph/Gutenberg-tutorials

Teoria sobre blocos no Gutenberg

Gutenberg está transformando o modo de se trabalhar com WordPress , onde você utiliza blocos para compor o seu conteúdo atualmente temos uma série de diferentes elementos para compor nosso conteúdo: títulos, parágrafos, conteúdo embedado, HTML, listas, images, galeria de imagem entre outros elementos.

A otimização do Gutenberg foi realizado de forma progressiva, isso significa que temos compatibilidade com o formato de conteúdo anterior com o novo editor. O Gutenberg oferece uma nova forma de se trabalhar com conteúdo distribuído em blocos e com um simples clique e arraste podemos alterar a ordem do conteúdo a qual será apresentado para os nosso usuários. Criando uma real experiencia WYSIWYG.

Blocos

Bloco é a unidade abstrata para organização do conteúdo, com um grupo de blocos montamos o nosso post. Podemos criar hierarquia de blocos, isso significa, podemos ter blocos com blocos filhos. Por exemplo, um bloco de duas colunas possuem um bloco filho pra cada coluna.

Para manter compatibilidade com versões anteriores armazenamos os blocos no banco de dados dentro da coluna wp_content como o WordPress armazena normalmente, com uma pequena diferença os blocos são representados por comentários em um formato entendido pelo back-end do WP se o site desativar o Gutenberg o conteúdo não será exposto para o usuário final. Um exemplo de bloco de paragrafo:

Por exemplo:

<!– wp:paragraph {“key” : “value”} –>
<p>Este é um bloco do gutenberg.</p>
<! — /wp:paragraph –>

No código acima quando o Gutenberg estiver ativado ele vai reconhecer como um bloco, caso não esteja ele será renderizado como um comentário HTML normal.

Blocos possuem duas categorias estáticos e dinâmicos, por exemplo, blocos estáticos apenas exibem um markup sem nenhuma edição no editor, apenas conseguimos definir a ordem dos elementos. Já os blocos dinâmicos exigem dados do banco e renderiza os elementos dinamicamente.

Cada Bloco contém seus atributos ou configurações, cada elemento pode ser alimentado por HTML puro, meta data ou diferentes origens. Uma feature do Gutenberg é a possibilidade criar blocos e copias dos tais, preservando o conteúdo ou apenas o markup. Mas podemos também limitar a quantidade de blocos que serão utilizados nos posts ou fixa-los em uma região específica.

Categorias de blocos

Quando acionamos o Block Inserter, abrimos um pop up com os blocos disponiveis, cada bloco terá um titulo e uma categoria. Podemos ter blocos nativos ou blocos customizados por plugins ou tema.

Blocos Reutilizáveis

Nos da a possibilidade de reutilizar blocos e repetir partes de um determinado conteúdo. Qualquer edição feita em um bloco reutilizável será replicado em todas suas cópias.

Templates

O Gutenberg tenta abstrair a estrutura HTML e permitir que o usuário foque apenas no conteúdo a nível técnico sua estrutura abstrai toda estrutura de um template único no formato clássico para uma coleção de elementos reutilizáveis e independentes.

Para entender como os blocos operam a nível de estrutura de dados, precisamos pensar na prensa de impressão de Johannes Gutenberg. A página era montada a partir de caracteres individuais até montar um texto, após a finalização do página os caracteres eram armazenados para serem utilizados em uma nova página.

fonte: https://infograph.venngage.com/p/148195/renaissance-innovations-project-the-first-printing-press-johannes-gutenberg

Nessa estrutura o conteúdo final não está atrelado a impressora, é só uma ferramenta base criação do conteúdo o resultado final não importa. Por muito tempo no desenvolvimento do temas clássico os templates eram páginas completas, agora esse paradigma mudou estamos em estruturas mais unitárias. Podemos recriar um tipo de layout sem precisar rescrever o template do zero.

O ponto principal dos blocos não é definir o resultado final mas sim agilizar o processo de criação de conteúdo.

Árvore de blocos

Além do conteúdo armazenado dentro da coluna post_content para manter a estrutura de correta dos blocos o WordPress criar uma descrição semântica em JSON chamada Tree of blocks ou árvore de blocos. Durante a execução, os blocos são mantidos na memória. Nesse momento, uma postagem do Gutenberg não é HTML, mas uma árvore de objetos e atributos associados. O Gutenberg se baseia em um modelo de dados que preserva a estrutura, de modo que os editores e visualizações para tipos específicos de blocos possam permanecer independentes do HTML final renderizado.

Exemplo:

[
{
type: “core/cover-image”,
attributes: {
url: “my-hero.jpg”,
align: “full”,
hasParallax: false,
hasBackgroundDim: true
},
children: [“Gutenberg posts aren’t HTML”]
},
{
type: “core/paragraph”,
children: [“Lately I’ve been hearing plen…”]
}
];

Como podemos ver existe muita coisa por trás do novo editor uma arquitetura complexa, mas que irá trazer um ganho muito grande para a plataforma. Espero detalhar mais pontos sobre o Gutenberg. Para não ficar uma leitura longa vamos finalizando por aqui nos próximos posts irei trazer mais conceitos chaves dentro do Gutenberg.

Esse post tomou como referencia o Handbook do WordPress leitura extremamente recomendada para você que trabalha com desenvolvimento de temas e plugins na plataforma.

Finalmente Gutenberg

No começo de dezembro de 2018 foi lançada a versão 5.0 do WordPress, posso falar de longe essa foi a versão mais controversa que eu já vi durante esses 10 anos que acompanho a plataforma. O ponto em questão foi o editor Gutenberg um update que muda toda a forma de se trabalhar com conteúdo dentro do WordPress. 

A nova forma de gerenciamento de conteúdo, vem com grandes mudanças devido a necessidade simples: evolução da plataforma, esse trabalho vem sendo realizado durante 2 anos, diversos testes e updates foram feitos. O projeto já venho acompanhando desde 2017, mas fiquei curioso para ver como seria a aceitação no twitter muitas e o resultado foi muitas pessoas reclamaram sobre o novo update. Um resumo do que eu vi durante essa semana foi:

1 – “comunidade” não foi ouvida

Muitas das reclamações no twitter foram que o update foi feito sem eles ouvirem a comunidade, se você esta mesmo engajado na comunidade, você deve ter ouvido falar do projeto Gutenberg a dois anos atrás, no último WordCamp US um dos temas chaves foi o Gutenberg, chats sobre updates eram realizados eram realizados. A resposta sim a comunidade foi ouvida. Muitas pessoas não sabem onde participar, isso é normal, outras só lembram do forum quando a coisa da ruim. Mas caso você queira participar: Meetups, WordCamps, Slack, forum são as formas oficiais de participar da comunidade. Twitter e facebook não são canais oficiais mas como o Mat Mullenweg falou no último WordCamp US comentários relevantes foram lidos nessas plataformas.

2 – Voce não é a maioria

Muito complicado quando entramos numa bolha pensamos que todo o mundo está no mesmo nível técnico que nós. Nos primeiros minutos da apresentação do Matt Mullenweg mostrou testes com usuários tentando colocar uma imagem ao lado de um texto, pode ser uma simples tarefa para você que sabe HTML e WP. Mas os testes mostram quão complexo é para um simples usuário e isso corresponde a +90% da internet. As principais mudanças do Gutenberg focam nesse grupo que mantem a plataforma.

3 – Acomodação

O conceitos de blocos é algo que afeta diretamente o ecossistema, está visível para todos os usuários diferente de uma REST API que funciona por trás das cortinas, um cliente normalmente não vai pedir uma REST API, Gutenberg vai estar lá para o usuário final vai ser comum clientes começarem a pedir blocos customizados. Aprender Gutenberg vai passar a ser algo relevante, mas a palavra aprender pode ser motivante para alguns devs e extremamente frustrante para outros. Uma pequena parte desse grupo que não gosta de atualizações, simplesmente lutam contra e fazem bastante barulho parecendo um grupo ainda maior. Dois anos atrás Matt veio na apresentação e disse estudem JavaScript e hoje o Gutenberg está ai com uma série de novas tecnologias que precisamos dominar, Dois pontos chave React e JavaScript e outras secundárias como EcmaScript 6, babel e Webpack. Já estão aparecendo soluções para simplificar nossa vida mas considero extremamente importante você ter uma base nessas tecnologias.

4 – Uma estrela não é contribuição

Uma chuva de reviews negativos no Gutenberg plugin, mas esse plugin foi diponibilizado para teste, essa era ideia os usuários testarem identificarem problemas. Era esperado que o plugin apresentasse algum erro, o usuário reportava a issue para ser corrigida. Marcar com uma estrela o plugin sem nenhum feedback não ajuda a plataforma. 

5 – Está tudo bem, você pode usar o editor clássico

O Gutenberg está ai mas você não é obrigado a utilizar, o desespero de muitos usuário poderia se resolvido com um simples clique para instalar o editor clássico novamente. O editor clássico não morreu vai estar disponível por mais dois anos. Gutenberg não está 100% tem muito para evoluir, esse update é um shift que vai revolucionar a plataforma, muita coisa ainda não está clara até o Matt Mullenweg, mencionou em sua palestra no WordCamp US, no decorrer do ano muita coisa vai ser definida, não por ele mas pela comunidade, como será feita a adoção, como os usuários irão reagir as mudanças.

A fase dois do Gutenberg já foi definido: https://make.wordpress.org/core/2018/10/05/gutenberg-phase-2-leads/

Caso queira acompanhar os updates do Gutenberg só manter o plugin instalado, as novas features serão criadas na versão do editor como plugin: https://wordpress.org/plugins/gutenberg/

Ciclo de vida de um componente react

Ciclos de vida de um componente react, um recurso importante dentro do React onde temos maior controle sobre nossa aplicação. Imagine você quer criar um Timer que irá contar somente quando o componente estiver sendo exibido na tela. Qual seria o evento que poderíamos incluir caso o componente fosse removido da tela? 

React nos fornece uma série de funções dentro do nosso componente, para cada fase do seu ciclo de vida. Podemos acompanhar quando:

  • Montado – Mounting
  • Atualizado – Updating
  • Desmontado – Unmounting
  • Dispara um erro – Error Handling

Eventos de montagem

Temos o constructor e a função render executados quando nosso componente é criado mas temos uma função especifica para quando nosso componente é criado componentDidMount(), essa função será executada após o constructor and render serem executados. Elas possuem a seguinte ordem:

  • constructor()
  • static getDerivedStateFromProps()
  • render()
  • componentDidMount()

Eventos de atualização

Quando nosso componente é atualizando chamamos uma série de funções na seguinte ordem: 

  • static getDerivedStateFromProps()
  • shouldComponentUpdate()
  • render()
  • getSnapshotBeforeUpdate()
  • componentDidUpdate()

As funções marcadas como bold são as funções mais usadas, o resto são utilizadas em casos bem específicos

Eventos de desmontagem

Temos um evento específico para quando nosso componente é removido do nosso. 

  • componentWillUnmount()

Mas vocês podem se perguntar mas porque que chamar uma função pra quando o meu componente for removido da tela. Podemos ter alguns casos, temos um formulário e o usuário não enviou os dados queremos salvar essa info caso ele volte para esse componente ou simplesmente remover um listener ou um Timer, nesses casos temos o controle de executar qualquer ação antes desse componente seja removido do virtual DOM.

Eventos de erro

Se algum erro ocorrer durante a renderização, durante alguma função do ciclo de vida ou no construtor de qualquer componente. filho.

  • static getDerivedStateFromError() 
  • componentDidCatch()

Durante a evolução do React algumas funções ficaram para trás e foram descontinuadas, são elas:

  • componentWillMount()
  • componentWillUpdate()
  • componentWillReceiveProps()

Essas funções não são mais recomendadas pelo time do React, são classificadas como UNSAFE.

Exemplo 1

No Exemplo 1, temos apenas a chamada do função componentDidMount() com o um console.log, para testarmos a ordem também adicionamos logs no construtor e no método render. E a saída será a seguinte:

Essa será a ordem de execução

Exemplo 2

No exemplo 2, incluímos mais funcionalidades em nosso exemplo, agora temos um timer para exibir a hora atual. Adicionamos a propriedade timer em nosso estado. E na função componentDidmount irá incluir um setIterval para atualizar o timer a cada segundo, mas para garantir nenhum tipo de erro removemos o setInterval antes de desmontar o nosso componente. Outra observação sobre a ordem de chamada das funções:

Cada vez que o estado é atualizado chamamos, render e a função componentDidUpdate

Introdução a Vue.js

Nessa guerra de novos frameworks javaScript, Vue.js aparece como mais um player promissor, com a promessa de um framework versátil, testável e performático. Sua adoção vem crescendo dia-a-dia. Mas essa não é a principal killer point da plataforma. Ele promete ser um framework progressivo, não utilizar um único monolitico, as modulos podem ser adicionados de acordo com sua necessidade, ou seja, podemos partir de aplicações simples até complexas aplicações adicionando os módulos Vuex(redux) e Vue-router.

Uma grande diferença do Vue é sua organização os componentes agrupam HTML, CSS e JS em um mesmo arquivo, definido como separação por interesse.

Um outro ponto para muitos uma vantagem que o framework não tem nenhuma empresa proprietário, como React(Facebook) and Angular(Google). O Vue é 100% opensource.

Se você possui conhecimento básico em  HTML, CSS e JS Vue é uma boa pedida, algumas empresas estão adotando a plataforma é aprender um novo framework antes do grande hype é um diferencial. Agora vamos ao que interessa, vou mostrar alguns recursos básicos do Vue.js.

Temos a opção de utilizar vue-cli, mas para esse exemplo vamos trabalhar com a CDN.

<script src="https://cdn.jsdelivr.net/npm/vue"></script>

Adicionamos a Vue ao nosso HTML:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Test Vue</title>
</head>
<body>
  <div id="app">
    {{ message }}
  </div>
  <script src="https://cdn.jsdelivr.net/npm/vue"></script>
  <script>
  	var app = new Vue({
      el: '#app',
      data: {
        message: 'Hello Vue!'
      }
    })
  </script>
</body>
</html>

Acabamos de criar o nosso primeiro app Vue.js, ele é bem simples mas já podemos ver algumas caracteristicas importantes. Dentro da div app temos um elemento com chave duplas esse é o padrão utilizado pelo Vue para indentificar as partes dinâmicas de nosso código, lembrando que esse trecho ficará conectado com nossa aplicação qualquer alteração desse valor será refletida em nosso DOM.

Após a chamada de nossa CDN temos o nosso código JavaScript, criamos um nova instância com os seguintes atributos, Qual elementos nossa aplicação irá apontar com “el”, qual os dados de nossa aplicação com “data” e assim nossa aplicação é inicializada.

Condicionais e loops

v-if

O atributo v-if é uma condicional “if” ela funciona como um toogle, se o nosso valor for true o conteúdo dentro da tag será exibido. Como podemos ver no exemplo acima, a variável ‘can_i_see_it’ e ‘can_i_see_it_2’ são vinculado a dois elementos só o primeiro span será exibido porque seu valor é true.  Notem quando utilizamos um atributo vue não precisamos utilizar as chaves duplas.

v-else

Temos a possibilidade de trabalhar com else utilizando a propriedade v-else, se não atribuirmos nenhum valor a propriedade funciona como um else normal podemos trabalhar com uma situação “else if” passando uma outra condicional. outro detalhe para esse exemplo dentro de data eu passo um objeto “question” com dois atributos(title and are_you_ready). Por exemplo para acessa o atributo title dentro do objeto question utilizamos {{question.title}}.

Trabalhando com Inputs

No exemplo acima temos um input vinculado com uma propriedade message através do atributo v-model que cria uma conexão two-way data binding.  Se testarmos o resultado a cada alteração do input será refletido na template tag {{message}}.

Para esse post temos nosso último exemplo:

Utilizamos o último exemplo e adicionamos um botão e vinculamos um método addMessage através to atributo v-on:click em nossa instancia Vue adicionamos um novo atributo methods e passamos os métodos que nossa aplicação irá possuir, nesse caso a cada click do botão salvar adicionamos o conteúdo do campo message a um array.

Com isso temos só um pouco que o framework pode fazer por nós, como nos exemplos acima não utilizei nenhum gerenciador de tarefas ou gerenciamento de bundle, mas podemos utilizar o vue-cli para ter um markup de uma aplicação.

A documentação do Vue é bem completa e está totalmente traduzida para português você pode conferir no link abaixo:

https://br.vuejs.org/v2/guide/index.html

O novo editor do WordPress: Gutenberg

Desde que o primeiro beta foi exibido no WordCamp Europe 2017, o novo editor do WordPress promete mudar 100% a experiência de edição de conteúdo do WordPress, vem sendo definido pela Automattic o novo “page and post building”. Algo que já vem sendo feito por plugins page builders a muito tempo, mas agora será um recurso default da plataforma e isso abrirá a possibilidade de um completo e novo ecosistema dentro da plataforma, o Editor já está disponível para teste como plugin mas será incorporado na próxima versão do WordPress 5.0.

Passado

Antes o editor visual cumpria seu papel quando era relacionado a publicação de textos simples, com a evolução da internet, a forma de postar e absorver conteúdo, e a penetração da plataforma na web (hoje presente em mais de 27% dos sites). Trouxe uma necessidade maior que o editor clássico não supria, a solução foi utilizar plugins page builders ou temas customizados integrados com metadados. Muitas vezes um usuário comum tinha que interagir com plugins muitas vezes complexos ou contratar um desenvolvedor para adaptar o WordPress para suas necessidades.

O que vem por ai?

O Gutenberg promete mudar a experiência antes uma grade texto corrido para uma estrutura de blocos independentes, cada qual com contextos específicos, assim facilitando a criação de conteúdo com layout customizado. Agora você poderá criar posts e páginas usando blocos com vários tipos de conteúdo e move-los dentro do post com mais facilidade, por exemplo, imagens, vídeos, conteúdo derivado das mídias sociais, widgets e o melhor de tudo o usuário final não precisa utilizar HTML ou CSS.

Como funciona?

Se você está ansioso para testar o Gutenberg ele está disponível atualmente em plugin para isso você instalar o plugin disponível no link:

Gutenberg

Update Jan 2019: Final de 2018 o Gutenberg foi incorporado como editor padrão do WordPress, a versão plugin ainda está disponível nela você poderá testar as versões de teste. E o editor clássico também não morreu ele está disponível como plugin: https://wordpress.org/plugins/classic-editor/

Caso tenha versões anteriores da versão 5.0, você precisa instalar como plugin e seguir os paços. Depois de instalado o Gutenberg irá modificar o seu editor clássico, para acessá-lo basta criar um novo post/página ou editar algo que já exista. Para ajudar você eu criei uma série de videos para explicar em mais detalhes como funciona o Gutenberg:

Para mais informações sobre o Gutenberg acesso o handbook:

https://wordpress.org/gutenberg/handbook/