DEV Community: Rafaell Lycan

GraphQL 101: The Basics

Rafaell Lycan — Sun, 30 May 2021 07:51:06 +0000

Introduction

GraphQL is a query language for APIs, it uses a type system that defines your information and runs on the server-side. It is not tied to a database or some information storage system, instead, is managed by the code that defines it.

It is based on the definition of types that allows consulting specific fields of objects and resolving the information required in the query.

Fields

"""
Type
"""
type Car {
    model: String!
    year: Int!
    manufacturer: String!
}


"""
Query
"""
{
    car {
        model
        year
        manufacturer
    }
}


"""
Data resolved
"""
{
    "data": {
        "car": {
            "model": "Maverick GT",
            "year": 1973,
            "manufacturer": "Ford"
        }
    }
}

In this simple example, we have a query in GraphQL that needs a car object that contains three fields: model, year and manufacturer. In a nutshell a field is a Scalar type and everything that is not an object, in this case, the fields within car resolve in Scalar types of type String.

The only object in this service is car which is composed of fields and defined as a type in the initial part of the query. For the context of this service, car is a type object that is composed by three fields.

In this way, we can write a query that checks inside the car object and returns all three fields.

Scalar Types

Since GraphQL is based on type definitions, it provides us with some Scalar types. These types allow the information to be resolved to a specific value, for example:

Int: A signed 32‐bit integer
Float: A signed double-precision floating-point value
String: A UTF‐8 character sequence
Boolean: true or false
ID: This Scalar Type represents a unique identifier of the object, this type is resolved as a String

GraphQL provides us the above established values, but it’s not restricting itself to these definitions only, some GraphQL services allow you to create your own Scalar Types with the condition that each one has to have defined the way to serialize and deserialize the information to communicate with the code that defines it, and the one who consults it.

Arguments

At first glance, GraphQL seems like a good way to obtain data, but the arguments provide a way to query the information concretely:

{
    car(id: "10"): {
        model
        manufacturer
    }
}

Each query can have 0 or N number of arguments. In the example above, we can filter the information through an id argument which filters and resolve information to only those cars which have the id 10.

Aliases

When making queries, you may need a way to distinguish the information returned by the query. This is made simple by adding aliases in your query:

{
    fordCars: car(manufacturer: "ford") {
        model
        manufacturer
    }
    chevyCars: car(manufacturer: "chevrolet") {
        model
        manufacturer
    }
}

"""
Data resolved
"""
{
    "data": {
        "fordCars": [
            {
                "model": "Maverick GT",
                "manufacturer": "Ford"
            }
        ],
        "chevyCars": [
            {
                "model": "Camaro SS",
                "manufacturer": "Chevrolet"
            }
        ]
    }
}

Aliases can be added to the query and specify changes to the name of the property. Aliases are particularly useful when having to rename a key on your output and to avoid duplication which will lead to an error.

Fragments

When the query becomes repetitive or at least some part of it we need a way to simplify it. For this particular scenario, we can use fragments which as the name suggests are fragments of types. The fragments help us to encapsulate a part of the type of data we need to reuse and make the same data request in different queries.

fragment carInformation on Car {
    model
    year
    manufacturer
}

"""
Query
"""
{
    fordCars: car(manufacturer: "ford") {
        ...carInformation
    }
    chevyCars: car(manufacturer: "chevrolet") {
        ...carInformation
    }
}

It might seem obvious, but this is super handy when you’re dealing with a repetitive shape in many different places.

Variables

Although this is self-explanatory, most of the time you will need to query the information dynamically, for example, the examples below using the manufacturer variables for a specific list of results, but we can give a step further by adding more variables to our query statically:

query CarByFord {
    fordCars: car(manufacturer: "ford", limit: 20) {
        model
        year
        manufacturer
    }
}

We call it static because the information that the cars that we will obtain will always be from the manufacturer "ford", but if we need to consult those that are from the manufacturer "chevrolet" we would have to write a new query. Let’s make some changes by defining a base:

query CarByManufacturer($manufacturer: String!, $limit: Int = 20) {
    car(manufacturer: $manufacturer, limit: $limit) {
        model
        year
        manufacturer
    }
}

With this approach, when executing the query and sending it the $manufacturer variable, it will be passed down as an argument in the query and will allow dynamic filtering of the information.

Also, as we can see we defined a default $limit to 20 directly in that query, and we could do the same for the manufacturer if needed. e.g.: always defaults to ford in the same way we did for $limit.

Also, you can identify that we’re using an exclamation (!) on $manufacturer only as it’s a mandatory variable on our query and there’s no default value.

Directives

So, if variables prevent us from writing more queries to carry out some default values in our query, in the same way, we have the directives which support dynamic modification of the data structure resolved on our query:

query CarByManufacturer($manufacturer: String!, $includeYear: Boolean = false) {
    car(manufacturer: $manufacturer) {
        model
        manufacturer
        year @include(if: $includeYear)
    }
}

If we execute the query with the following variables, we will obtain a car fix with the manufacturer’s registration dodge but without including the manufacturer’s year due to the default value of $includeYear is false and using the @include directive which will modify our output:

"""
Variables
"""
{
    "manufacturer": "dodge"
}

"""
Data resolved
"""
{
    "data": {
        "car": [
            {
                "model": "Charger R/T",
                "manufacturer": "Dodge"
            }
        ]
    }
}

Now, let’s use the @skip directive instead, which will be skipped only if $excludeYear is true:

query CarByManufacturer($manufacturer: String!, $excludeYear: Boolean = false) {
    car(manufacturer: $manufacturer) {
        model
        manufacturer
        year @skip(if: $excludeYear)
    }
}


"""
Variables
"""
{
    "manufacturer": "dodge"
}

"""
Data resolved
"""
{
    "data": {
        "car": [
            {
                "model": "Charger R/T",
                "manufacturer": "Dodge",
                "year": 1969
            }
        ]
    }
}

Both @include and @skip alongside with @deprecated are part of the GraphQL specification so you can use it freely, but if needed you can also implement your own.

Mutations

So far we have only seen how to fetch data, but GraphQL also supports data modification. Most requests in REST APIs allow data querying using the GET method, which by convention should not be used in an action that triggers the data modification, like POST for creation and PUT/PATCH for update.

As GraphQL uses POST by default, any operation that modifies data should be sent specifying that it is a Mutation.

mutation CreateNewCar($model: String!, $year: Int! $manufacturer: String!) {
    createCar(model: $model, year: $year, manufacturer: $manufacturer) {
        model,
        year,
        manufacturer
    }
}

A Mutation can return the data of the resource created, which means that we can ask for any of the fields on the object we just created.

Pros & Cons

Pros

It is based on type definition which can reduce the communication error between the client and the server.
It works as a single entry point for an API, which also makes it flexible to make requests and modifications.
Again talking about types, especially when working with a strongly typed language, it allows seamless and type-safe request/response contracts with your app.
It allows good scalability of the API and integration with different services reachable only via REST calls.

Cons

In addition to creating robust and typed backend code, developers also have to create and maintain those schemas which must be always updated and cohesive.
The learning curve for those who are used to working with REST APIs is higher.
Much of the processing of queries is done on the server, and therefore complex queries and mutations will cost more time to be processed.
Migrating from a REST API to GraphQL is usually difficult and quite expensive, which leads to adopting it as a proxy to existing APIs a common choice.

Conclusion

The flexibility that GraphQL provides us for communication between the backend and frontend definitely creates a rapid development of client-server applications.

The backend is entirely in charge of providing the type definitions and resolvers while the frontend only has to worry about knowing the data structure and how to perform queries and mutations from the client itself. In addition, by having a single entry point for making queries, the client can completely forget about the definition of urls and use a unique way to make those requests.

GraphQL was created by Facebook initially in 2012 and released publicly in 2015, and since then the maturity and adoption have grown which allowed companies to experiment and take into account the migration to this type of API or simply use it as a proxy to their services.

Credits

A special thanks to Anton Virtanen for reviewing this article so quickly.

7 Dicas que todo desenvolvedor React deveria saber

Rafaell Lycan — Tue, 04 Dec 2018 00:00:00 +0000

Muitos de nós, devs front-end, devs JavaScript e também devs React ~~hype do momento~~ trabalhamos em equipes com vários outros desenvolvedores com diferentes níveis. Um dos melhores métodos para melhorar seu código é através do “Code Review” , porem, nós não só verificamos como tudo funciona, mas também vemos como nossos companheiros chegaram a tal resultado afim de garantir um código limpo e claro.

Mas por que? Bom, é até bem simples, uma vez que você trabalhe em uma equipe de 5 desenvolvedores no mesmo projeto, fica fácil perguntar diretamente como as coisas funcionam e porque das decisões. Mas se você trabalha em uma equipe grande, com vários times em projetos diferentes onde tudo muda muito rápido, manter esse “padrão”/”código limpo” simples e entendível, vai nos ajudar e também a outros desenvolvedores a entender melhor o que seu código faz e se tudo esta de acordo com as melhores práticas.

Eu escolhi 7 boas práticas que ajudaram a mim e ao meu time a melhorar o padrão dos nossos projetos em React. Então deem uma boa olhada e sintam-se livre para utiliza-los também.

1 - Use componentes funcionais.

Todos nós estamos muitos felizes e gratos que ES6 trouxe o suporte a classes e provavelmente você também ama isso. Em React nós podemos criar um componente apenas extendendo React.Component, onde podemos ter um state , ciclo de vida , event handlers , etc. Mas nem sempre precisamos de tudo isso, mas como sabemos que podemos utilizar.

class MyComponent extends Component {
  render() {
    return <h1>Hello {this.props.name}</h1>
  }
}

Mas as vezes, muitos desenvolvedores se esquecem que talvez esse componente seja dummy , ou seja, não necessite de um state interno** ou ciclo de vida. Um componente funcional como o nome sugere, é uma função que recebe props como parâmetro e retorna um React.Element.

const MyComponent = (props) => {
    return <h1>Hello {props.name}</h1>
};

// Ou simplesmente 

const MyComponent = (props) => <h1>Hello {props.name}</h1>;

Ok, mas por que eu deveria utilizar um componente funcional? Simples, eles são muito mais simples pois não precisam extender uma classe, alem de facilidade para entender e testar além de escrever menos código e garantir que seu componente será sempre stateless e não precisará lidar com this binding para métodos internos, o que ajuda na refatoração para componentes menores quando precise.

Ok, então quando eu preciso extender componentes ou criar componentes funcionais? A regra é clara , quando você precisar de algo que um componente funcional não tem (state interno, lifecycle, event handlers) use uma classe para extender um componente!

O que me leva ao seguinte tópico…

2 - Mantenha seus componentes pequenos.

Componentes pequenos são mais fáceis de ler e testar além de reutilizar e manter. Aqui temos um simples exemplo de Comments onde exibimos as informações de um comentário bem como seu criador.

class Comment extends Component {
  render() {
    return (
      <div className="comment">
        <div className="user-info">
          <img className="avatar"
            src={this.props.user.avatarUrl}
            alt={this.props.user.name}
          />
          <h4 className="user-info__name">
            {this.props.user.name}
          </h4>
        </div>
        <div className="comment__text">
          {this.props.text}
        </div>
        <div className="comment__date">
          {this.formatDate(this.props.date)}
        </div>
      </div>
    );
  }
}

A primeira coisa que já percebemos é que os dados do usuário poderiam ser extraídos em um novo componente UserInfo, o qual receberia apenas as propriedades necessárias para renderizar e assim garantir um componente mais simples , testavel e manutenivel.

Como o componente apenas renderiza os dados informados em props vamos utilizar um componente funcional como exemplo:

const UserInfo = (props) => {
  return (
    <div className="user-info">
      <img className="avatar"
        src={props.user.avatarUrl}
        alt={props.user.name}
      />
      <h4 className="user-info__name">
        {props.user.name}
      </h4>
    </div>
  );
}

Pronto! E podemos substituir todo o bloco em Comment por nada mais que <UserInfo user={this.props.user} />. Muito bem! Mas ainda poderíamos ainda extrair a imagem para um componente Avatar para deixa-lo ainda menor e reutiliza-lo onde for necessário:

const Avatar = (props) => {
  return (
    <img
      src={props.user.avatarUrl}
      alt={props.user.name}
    />
  );
}

E com isso você simplesmente utiliza <Avatar user={props.user} /> em seu componente UserInfo, o que novamente vai te garantir simplicidade , testabilidade e manutenibilidade. Melhor? Bom, sim e não, este foi apenas um exemplo, mas muitas vezes você vai se deparar com casos como esse onde você não vai precisar dar muita importância, tudo vai depender da complexidade que você tem.

3 - Entenda como lidar com `this`

Lembra da dica 1? Componente funcionais não precisam de bind(this) o que nos permite utilizar-los sempre que possível, mas no caso de classes, precisamos realizar o binding manualmente uma vez que o React não faz isso para nós automaticamente. A mais de uma forma de realizar o binding, um deles é fazer bind diretamente na função render:

class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = { message: 'Hi' };
  }

  logMessage() {
    console.log(this.state.message);
  }

  render() {
    return <input type="button" value="Log" onClick={this.logMessage.bind(this)} />
  }
}

Isso definitivamente funciona, mas o problema aqui é que uma nova função é chamada a cada vez que este componente é renderizado, o que pode te causar alguns pequenos problemas de performance dependendo de quantos componentes você possui na mesma view e quantas vezes esses componentes são atualizados.

Uma outra maneira é utilizar Arrow Functions no método render, o que também é funciona.

class MyComponent extends Component {
  ...

  render() {
    return <input type="button" value="Log" onClick={() => this.logMessage()} />
  }
}

Aqui temos o mesmo problema, pois mesmo que não seja necessário realizar o bind(this) manualmente, estamos criando uma nova função para cada vez o componente for renderizado, logo é apenas uma questão de preferência, uma vez que ambos terão pequenos problemas de performance.

Acredito que a maioria de vocês já esteja familiarizado com o método mais comum, onde realizamos o bind diretamente no construtor :

class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = { message: 'Hi' };
    this.logMessage.bind(this);
  }

  logMessage() {
    console.log(this.state.message);
  }

  render() {
    return <input type="button" value="Log" onClick={this.logMessage} />
  }
}

Desta maneira não criamos o problema de performance como nos métodos anteriores, o que é perfeito para qualquer aplicação. O único problema para mim é a repetição, e com isso eu preciso dizer que amo ES6 , em especial arrow functions , onde de maneira simples podemos utilizar diretamente no método da classe e evitar tanto o problema de performance quanto a repetição do binding no construtor.

class MyComponent extends Component {
  static state = { message: 'Hi' };

  logMessage = () => {
    console.log(this.state.message);
  }

  render() {
    return <input type="button" value="Log" onClick={this.logMessage} />
  }
}

Apenas tenha em mente que esta é uma feature em experimento e ainda não esta disponível oficialmente na especificação do ES6, mas você pode utilizar isso hoje utilizando Babel ou simplesmente utilizando Create React App que já possui várias features habilitadas.

4 - Use uma função para `setState` ao invés de um objeto.

De acordo com o a documentação oficial, o React não garante que as mudanças são aplicadas imediatamente, uma vez que o processo é assíncrono, onde se você precisa ler uma propriedade de state logo após utilizar setState() pode gerar alguns efeitos colaterais uma vez que o dado pode ainda não ter sido atualizado.

// Ao invés disso
this.setState({showPagination: !this.state.showPagination})

// Faça isso
this.setState((state, props) => {
  return { showPagination: !state.showPagination };
))

Você pode utilizar uma função que recebe dois parâmetros state anterior e as props do seu componente, onde todo este processo ocorre de maneira síncrona, o que pode evitar potenciais bugs na sua aplicação.

5 - Use Prop Types e Default Props sempre que possível.

Durante o desenvolvimento da sua aplicação, você provavelmente compartilha valores via propriedades entre seus componentes, logo se um de seus componentes recebe um texto, este texto deveria ser uma string correto. Digamos que você tem um componente que recebe um texto como parâmetro obrigatório e que você utiliza o método toLocaleUpperCase() o qual é exclusivo para strings, porem você se depara com um valor do tipo number? E quanto a undefined?

Prop-Types é uma biblioteca para nos ajudar a previnir bugs garantindo que estamos informando o tipo certo de dado para um componente.

import PropTypes from 'prop-types'

class MyComponent extends Component {
  render() {
    return <h1>Hello {this.props.name.toLocaleUpperCase()}</h1>
  }
}

MyComponent.propTypes = {
  name: PropTypes.string.isRequired
}

De maneira similar, mesmo garantindo que aceitamos um certo tipo de dado, talvez nossa API não retorne um valor que não é obrigatório em nossa aplicação, e sendo assim devemos adicionar defaultProps uma vez que nosso propType não é mais obrigatório o que vai garantir que você e seus companheiros desenvolvedores não esqueçam de fornecer algum dado para um componente ou simplesmente para previnir algum bug inesperado.

import PropTypes from 'prop-types'

class MyComponent extends Component {
  render() {
    return <h1>Hello {this.props.name.toLocaleUpperCase()}</h1>
  }
}

MyComponent.defaultProps = {
  name: 'World'
}

MyComponent.propTypes = {
  name: PropTypes.string
}

6 - Utilize React Fragments.

Você recebeu ou criou um layout todo em HTML, com as melhores práticas de web semântica e tudo parece lindo. Agora tudo o que você precisa é implementa-lo em React, começando pela header até ficar perfeita… logo então o bloco de conteúdo … perfeito… oops… esquecemos que precisamos criar um wrap para isso… ah não… react… merda! 😢

Isso é um problema bem comum na verdade, onde por um longo tempo, onde tínhamos que criar um wrap para tudo:

class MyComponent extends Component {
  render() {
    return (
      <div>
        <header>Header 😐</header>
        <main>Main Content 😢</main>
      </div>
    )
  }
}

E por conta disso sempre adicionávamos um novo elemento ao nosso DOM por conta disso, mas felizmente existe algo chamado “React Fragments” desde a versão 16, o que nos permite construir uma aplicação sem ter que adicionar um wrap para agrupar elementos no nosso DOM. A utilização é a mesma, porem ao invés de utilizarmos uma div nós usamos um <React.Fragment></React.Fragment> ou o shorthand <></>

class MyComponent extends Component {
  render() {
    return (
      <React.Fragment>
        <header>Header 😎</header>
        <main>Main Content 😝</main>
      </React.Fragment>
    )
  }
}

Ou simplesmente…

class MyComponent extends Component {
  render() {
    return (
      <>
        <header>Header 😎</header>
        <main>Main Content 😝</main>
      </>
    )
  }
}

Se você ainda não sabia disso, seu dia acaba de ficar mais bonito. De nada 😎

7 - Utilize “React Developer Tools”

Acho que essa dica todos já sabem e utilizam, mas por via das dúvidas, para você que chegou neste artigo e ainda não tem conhecimento sobre isso, React Developer Tools é uma extensão disponível para Chrome e Firefox que nos permite inspecionar a hierarquia dos componentes em nossa aplicação bem como as props e o state de cada um dos seus componentes, que é sem dúvida uma ferramenta muito útil e valiosa para debugar e analisar o código da sua aplicação.

Conclusão

Acredito que muitos destes 7 pontos já são de conhecimento comum, mas também acho importante compartilhar o que aprendi nestes últimos anos trabalhando com React em diferentes aplicações e como manter um padrão de código limpo e de fácil manutenção, sem contar que estes fazem parte de um conjunto de boas práticas adotadas por mim e pelo meu time.

Sinta-se a vontade para comentar e compartilhar qualquer outra dica que você considera importante, uma vez que estes 7 pontos são apenas algumas coisas que julguei importante resaltar para aqueles que estão começando a trilhar seu caminho neste mundo. Não achei tão importante falar sobre conditional rendering , absolute imports ou estrutura de projetos pois acredito que isso varia muito de cada projeto e da mentalidade de cada time, mas tão pouco tiro a importância de cada um. Talvez vire um futuro artigo.

As 5 novas features em React 16.6

Rafaell Lycan — Sat, 03 Nov 2018 00:00:00 +0000

Por mais que tenha a aparência de um minor release, a versão 16.6 do React lançada na última semana, nos traz novos recursos, como o tão esperado Suspense API , e também o novo HoC memo e a função lazy. Veremos um pouco mais sobre os 5 novos recursos desta versão ✨

1 - Memoização com `memo`

Lembrando que existem várias maneiras de criar um componente com React:

Com classes extendendo `Component`

Neste exemplo, podemos utilizar métodos para controlar o estado e ciclo de vida do componente. Por padrão, ele é renderizado novamente a cada mudança (é possível otimizar com shouldComponentUpdate).

class Button extends Component {
  render() {
    return <button />;
  }
}

Com classes extendendo `PureComponent`

Neste exemplo assim como no anterior, nos permite controlar o estado e ciclo de vida do componente através de métodos, porem, ele só será renderizado novamente se uma de suas props forem alteradas.

class Button extends PureComponent {
  render() {
    return <button />;
  }
}

Com funções (stateless)

Neste exemplo mais recente, podemos criar um componente sem a necessidade de controle estado ou ciclo de vida, e como Como um class Component, esse tipo de componente é renderizado novamente a cada mudança.

const Button = () => <button />;

Um componente stateless (ou componente funcional), será renderizado novamente sempre que houver uma mudança no componente pai. Esse comportamento pode causar problemas de desempenho.

✨ Introduzindo `memo` ✨

Para evitar isso, agora podemos usar o HoC memo, que adota o mesmo comportamento que o PureComponent, prevenindo assim renderizações desnecessárias:

const Button = React.memo(() => <button />);

💡Assim como o PureComponent, memo compara apenas as propriedades no primeiro nível do objeto, ou seja, se suas propriedades contém objetos, a verificação será baseada no ponteiro de memória desse objeto (equal), e não no conteúdo em si (deep equal). Você pode passar um segundo argumento com a sua própria função de comparação:

React.memo(CustomComponent, _.isEqual);

2 - Code-Splitting com `lazy`

Code-splitting torna possível reduzir o tamanho/bundle da nossa aplicação criando assim sub-bundles. O usuário não precisa/deveria baixar todo o código da nossa aplicação se ele não for utilizado.

Hoje Webpack gerencia muito bem essa divisão através de code-splitting, desde que você faça o necessário ao importar seus componentes. Agora ficou ainda mais fácil com a função lazy, que permite importar dinamicamente outros módulos/componentes em tempo de execução:

const Admin = React.lazy(() => import('./routes/Admin'));

const App = () {
  return (
    <div>
      <Admin />
    </div>
  );
}

Neste exemplo, todas as dependências do componente Admin serão colocadas em um bundle diferente. Isso permite um ganho considerável na inicialização da sua aplicação.

⚠️ Alguns pontos importantes

Vale lembrar que a função lazy ainda não é suportada em SSR, neste caso existem bibliotecas como react-loadable para nos ajudar.

A função lazy recebe uma função para realizar a importação dinamica import(). Isso retorna uma Promise que espera um módulo com exportação default que contém um componente, isso significa que em nosso exemplo Admin teria de ser exportado como export default Admin;. Caso você não possa/queira utilizar export default, existe uma solução para mapear o módulo:

React.lazy(() => import('./routes/Admin')
  .then(component => ({ default: component.Admin }))
)

3 - Suspense API

Outra novidade deste lançamento e acredito que a mais aguardada é a Suspense API. Ainda que experimental (ainda não está pronta em relação à parte de recuperação/cache de dados) porem, você já pode usá-lo com code-splitting e com a função lazy. Com ambos combinados, poderíamos exibir um feedback para o usuário durante o carregamento do módulo:

const Admin = React.lazy(() => import('./routes/Admin'));

const App = () => {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <Admin />
      </Suspense>
    </div>
  );
};

Nós teremos que esperar um pouco para utilizar totalmente essa API sem os problemas conhecidos, mas ela funciona perfeitamente com rotas, utilizando por exemplo a biblioteca react-router-dom, que carrega assim o bundle de diferentes páginas apenas quando necessário.

4 - Mais facilidade com `contextType`

Introduzido anteriormente na versão 16.3, a nova Context API generalizou o uso desse padrão em nossas aplicações. Lembrando que esta API permite que nossos componentes se inscrevam em um contexto para ler os dados e evitar a necessidade de transmissão de props de um componente a outro.

Na prática, este é um exemplo antes de contextType:

const ThemeContext = React.createContext('light');

class App extends React.Component {
  render() {
    return (
      <ThemeContext.Provider value="light">
        {this.props.children}
      </ThemeContext.Provider>
    );
  }
}

class ThemedButton extends Component {
  render() {
    return (
      <ThemeContext.Consumer>
        {theme => <Button theme={theme} />
      </ThemeContext.Consumer>
    );
  }
}

const Toolbar = () => (
  <div>
    <ThemedButton />
  </div>
);

Com o novo método estático contextType, podemos nos livrar do componente ThemeContext.Consumer:

class ThemedButton extends Component {
  static contextType = ThemeContext;

  render() {
    return <Button theme={this.context} />;
  }
}

Aqui o contextType injeta automaticamente o ThemeContext e assim temos acesso ao this.context ✌️.

5 - Gerenciando erros com `getDerivedStateFromError`

A versão 16 do React foi introduzido o conceito de “Error Boundaries” através do método componentDidCatch no ciclo de vida dos nossos componentes, mas mesmo assim existem alguns problemas em alguns cenários além de não ter suporte para SSR.

A nova função getDerivedStateFromError permite a interceptação antes da nova renderização do componente (a função render pode retorna null com o componentDidCatch).

Até a próxima! 💪⚛️

Qual é o custo de vida em Barcelona?

Rafaell Lycan — Mon, 22 Oct 2018 00:00:00 +0000

Antes de tomar a decisão de se mudar para Barcelona, você provavelmente se pergunta qual é o custo mensal de viver aqui. Por mais que seja fácil, eu gostaria de compartilhar esses dados fundamentais antes de decidir sobre qualquer destino. Vamos verificar qual é o custo mensal de vida em Barcelona.

Se você pesquisar, provavelmente notará que os preços de aluguel em Barcelona estão aumentando. No entanto, o custo total de vida na cidade (considerando comida, entretenimento e transporte, etc.) é considerado mais baixo do que muitas das principais cidades da Europa. Mas como você pode saber se a renda que você tem/terá, será suficiente para viver e manter um certo nível de vida em Barcelona?

Custos de acomodação

Os preços variam dependendo de onde você olha: bairros de alta demanda como Grácia , Eixample , El Born , Barri Gotic e Poblenou vão custar muito dinheiro, mesmo para um apartamento de baixa qualidade. Os bairros como Les Corts , Sants ou La Sagrera também são muito bons e os aluguéis são um pouco mais baixos. Você também pode encontrar algo interessante na minha vizinhança favorita, o Poble Sec.

Se você planeja se mudar, pode dividir um apartamento com outras pessoas por 350-500€/mês por um quarto, ou alugar um apartamento de um quarto por 650-850€/mês. Se você é casado e tem filhos, por 800-1000€ você pode obter um muito decente 60-80m2, 2 ou 3 quartos, e as vezes até com 2 banheiros.

Além do aluguel, há um depósito caução chamado “fianza” exigido ao alugar um apartamento, o qual normalmente te obriga a pagar um depósito de 2 meses, mais a taxa do agente imobiliário, que é de 1 mês de aluguel ou 10% do aluguel anual.

Se você não se importar de viver mais longe da cidade, você pode encontrar lugares mais barato em cidades próximas como L’Hospitalet de Llobregat , Badalona , Rubi e Sabadell que estão a menos de 1h do centro de Barcelona.

Resumindo:

Alugar por um quarto: 350-500€
Alugar para estúdio: 650-850€
Alugar para um apartamento de 2 ou 3 quartos: 800-1000€
Taxa de agência imobiliária: 1 mês de ou 10% do aluguel anual
Depósito caução: Normalmente 2 meses de aluguel

Esteja preparado que o primeiro mês do seu aluguel você precisará pagar antecipadamente de 3-4 vezes o seu aluguel mensal. Dependendo se você aluga seu apartamento através de uma agência ou não. Muitas vezes você pode não ter que pagar a taxa da agência se você alugar direto com o proprietário, mas claro, sempre que tenha um contrato, não seja enganado.

Alguns sites que você pode pesquisar sobre o valor dos alugueis são o Idealista, Fotocasa ou Habitaclia, e especificamente para quartos existem apps como o Badi e o Spotahome.

Contas básicas

Suas contas vão dependem muito, pois você terá que pagar por eletricidade, água, gás e internet se optar por morar sozinho, a única coisa que normalmente estará incluso é o condomínio. Isso é exceção se você estiver alugando um quarto, pois normalmente estas contas já estão inclusas.

Como indicado básico, vou usar como exemplo o meu apartamento de 65m2 para duas pessoas.

Eletricidade: 70€
Água: 35€ (a cada 2 meses)
Gás: 0€
Telefone fixo: 0€
Celular: 10€ por um plano de 5GB
Internet: 50€ por uma fibra de 300MB + plano de celular de 20GB

OBS: Essa foi a média dos últimos 6 meses, e no meu caso tudo é elétrico, por isso não pago pelo gás, o que encarece minha conta de eletricidade, e também não utilizo um telefone fixo.

Alimentação

No meu caso, para duas pessoas, gostamos de comprar as coisas que vamos comer para a semana, e compramos o “grosso” apenas 1x ao mês quando precisamos.

A compra básica normalmente fazemos em mercados de desconto como Aldi , Lidl , Consum e Mercadona : 40-60€
E semanalmente gastamos em média entre 20-25€

É possível gastar menos que isso caso você não compre toda semana coisas como bebidas, carne vermelha (bovina) e outras porcarias que não são essenciais.

Lista de preços para produtos populares:

Leite 1.5 litros: 1,20€
12 ovos: 1,29€
Pão baguete: 0,70€
Margarina 500g: 2,89€
Bananas 1kg: 1,19€
Batata 1kg: 1€
Tomate 1kg: 2€
Café 250g: 2,49€
Açúcar 1 kg: 0,75€
Cerveja lata: 0,60€
Pasta de dente: 1,40€

Transporte público

Passagem para uma viagem: 2,20€
Passagem T10 (10 passagens): 10,20€
Bilhete mensal: 54,00€
Bicing (bicicleta da cidade): 50€

Um táxi do centro da cidade (Pl. Catalunya) até o aeroporto El Prat custa em média 35-40€, mas em geral você pode utilizar uma bicicleta para se locomover e ter um T10 em mãos caso chover ou precise ir para lugares muito distantes.

Veja mais sobre bilhetes e seus preços no site da TMB e também como funciona o Bicing aqui.

Outros gastos

Ingresso de cinema: 8,50€ (às quintas o ingresso custa 5,90€)
Academia: 23-45€
Corte de cabelo: 14€
Cabelo + Barba: 24€
Cerveja pequena (caña/330ml) em bar: 2-2,50€
Cerveja em um pub (pinta/500ml): 5,00€
Espresso/cortado/cafezinho: 1,20€
Jantar em um bom restaurante (para 2): 45-60€
Entrada em clubes (geralmente inclui uma bebida): 15-20€ (embora normalmente seja grátis antes das 2h
Plano de saúde: A partir de 43€ (O hospital público é bom, mas estudantes, turistas ou quem está ilegal não têm o direto de usar).

Também existem lugares baratos como o 100 Montaditos ou o La Sureña onde você pode comer e beber e não gastar nem 20€.

É possível encontrar filmes na versão original (VOSE) ou dublado em espanhol. Eu pessoalmente recomendo Yelmo , Cinesa e Renoir , além de que todos os museus são gratuitos no primeiro domingo do mês.

Conclusão

O custo de vida em Barcelona não é super barato já que é considerada a cidade mais cara da Espanha, mas é possível ter mais qualidade de vida mesmo com um orçamento baixo diferentemente do Brasil.

Se você tem um orçamento de 1200€ ou mais, é possível viver confortavelmente em Barcelona, mas também conheço algumas pessoas que ganham menos de 1000€ e que moram dividindo apartamentos, e mesmo com a grana esta curta ainda compram sua própria cerveja para levar para praia, ou fazem alguns lanches (bocadillos) e vão no parque Ciutadella/Montjuic, etc. Além de viajar algumas vezes por ano.

Ah, se você quiser fazer referência cruzada de Barcelona para a qualidade de vida, ganhos e gastos com outras cidades interessantes em todo o mundo, visite Teleport.org. É uma ótima ferramenta para comparar os níveis de vida em diferentes cidades do mundo.

Como eu uso Git!

Rafaell Lycan — Tue, 04 Sep 2018 00:00:00 +0000

Depois de algumas pessoas me verem utilizar Git e como eu o configuro para facilitar a minha vida, achei interessante compartilhar como utilizo no meu dia a dia, incluindo assim algumas práticas que você pode utilizar também.

Se você não esta familiarizado ou não conhece Git, escrevi um artigo básico sobre Git e Github no passado, mas você também pode aprender com este exemplo do Tableless que também esta bem completo.

Obtendo Informação

Percebi a pouco tempo que não consigo estar contente com terminal/git tendo o tema padrão que vem no sistema operacional. No MacOSX recomendo utilizar o iTerm2 junto ao ZSH o que me habilita o nome da branch e também cores. Quer dizer, fica é legal:

Um dos comandos que eu mais utilizo é o git status, e convenhamos que é um pouco chato escrever isso todo o tempo, então criei um atalho (alias) para git st para deixa-lo um pouco menor. Uma outra coisa importante, especialmente quando se utiliza rebase é ver como o histórico esta.

Para isso utilizamos o git log, mas ainda assim é um comando que nos traz muita informação que as vezes não é necessária, além de não ser fácil de fazer uma leitura rápida. Para isso eu uso git lg que é um pequeno atalho para git log --pretty=oneline --abbrev-commit --graph --decorate. Eu realmente não vou digitar isso.

Ele vai criar uma espécie de gráfico contendo apenas ID do commit, a mensagem, o nome da branch, etc. Algo assim:

Se por algum motivo você ainda pensar que precisa de toda aquela informação, você poderia simplesmente utilizar algo como git log --graph --abbrev-commit --decorate --date=relative que seria algo assim:

Trabalhando com Branches

Para mudar rapidamente de branches, criei alguns atalhos. Como na maioria das empresas que trabalhei até hoje, utilizamos algo parecido com o _ git-flow _, onde a branch master que contem nossa versão de release, e a develop como principal, onde ambas são protegidas contra commits. Tudo é adicionado através de pull-requests em nossa branch principal.

Eu criei atalhos como git co para git checkout e git br para git branch:

$ git br -D feature/feature-a
$ git co -b feature/feature-b

Para tornar tudo ainda mais fácil entre as branches (o que acontece bastante especialmente mudando para develop), criei git com e git cod respectivamente para ter atalhos diretos.

Trabalhando com Git

Além do que já vimos, também não podemos fugir do fluxo de adicionar novos arquivos e finalmente criar nossos commits e fazer push para o repositório.

Eu tenho criei um atalho específico para add porque não acredito que iria me trazer alguma melhor muito grande, mas quando você pode adicionar vários arquivos de uma vez, criei git all para git add . que hoje é algo automático que faço algumas vezes por dia. Também criei um atalho para git commit -m usando git cm

$ git all
$ git cm "Adicionando módulo XYZ junto ao main da aplicação"
$ git push

Quando falamos em enviar nossos commits para o repositório, eu normalmente prefiro evitar adicionar o nome da minha origem (normalmente origin) seguido pela branch por diversos motivos:

Git Push deveria enviar sempre utilizar o comando push sem precisar de parâmetros, enviando assim para sua branch atual ou cria-la caso a mesma não exista.
Acredito que este valor default que pode ser modificado na configuração provavelmente possui algo relacionado a segurança, uma vez que não vem habilitado o valor current por padrão, por isso eu atualizo meu .gitconfig e convenci o pessoal do meu trabalho a fazer o mesmo para simplificar nossas vidas:

# https://git-scm.com/docs/git-config#git-config-pushdefault
[push]
  default = current

Desfazendo seus commits

Particularmente eu não gosto dos comandos a cada vez que quero voltar a um certo ponto, um exemplo é git reset --soft HEAD^, o que isso realmente faz? Eu resolvi esse problema com poucos atalhos.

Para desfazer meu último commit, eu criei git undo (atalho para git reset --soft HEAD^) o deletará o último commit do histórico mas mantem minhas mudanças indexadas no caso que eu queira modificar algo. Para tirar as coisas do meu index (o contrário de git add) eu criei git wait (para git reset HEAD). E para remover os arquivos totalmente do meu index, eu criei um atalho para git checkout . em git abort, o qual venho utilizando algumas vezes quando quero remover mudanças inúteis depois de adicionar linhas para debugar um certo arquivo.

$ git undo # Desfaz meu último commit
$ git wait # Remove os arquivos em "staged" fora do index
$ git abort # Remove qualquer alteração nos arquivos indexados

Rescrevendo seu Histórico

Quando trabalhamos com branches, eu particularmente muitas vezes reescrevo meus commits (especialmente o último), com o objetivo que quando minha feature esta completa, o histórico da sua branch deveria ser limpo e auto explicativo a cada commit, para que quem esteja revisando meu PR tenha uma ideia do que ocorreu a cada commit antes mesmo de olhar o código.

$ git lg

* 849094a SQ3-309 Add new Redux Actions for Content module
* eb6d23d SQ3-309 Refactor ContentLibrary Columns
* 3249ed6 SQ3-309 Change API Base URL for the API
* eab0563 SQ3-309 Change Server mock impl for pagination feat
* cd6acfb SQ3-309 Add dropdown with actions
* 27c5f98 SQ3-309 Fix ContentLibrary styles
* b8fe782 SQ3-309 Add Redux Thunk and Axios to use the API instead Backbone Model/Collections
* 2e5b44a SQ3-309 Add content API mock endpoint
* 04e548e SQ3-309 Add SASS for ContentLibrary module
* 34b9b43 SQ3-309 Add ContentLibrary module to the project

Para chegar a este pequeno exemplo, reescrevi a mensagem de commit e utilizei rebase para garantir que as mensagens faziam sentido. Eu sinceramente acho que as pessoas não gostam de rebase. Rebase é uma ferramenta muito útil para corrigir seu histórico e faze-lo ter algum sentido. Você não é obrigado a fazer isso, é apenas algo que aprendi e me acostumei depois de algum tempo trabalhando com Git , e eu gosto de utiliza-lo para limpar minhas branches antes de abrir um PR, e até conheci alguns desenvolvedores que trabalham da mesma forma.

Eu realmente faço muitos rebases interativos, meu workflow normalmente se resume em: fazer o commit; perceber que esqueci alguma informação na descrição do commit ou ter editado algum arquivo relacionado ao commit; atualizar o commit; Fazer push para o repositório remoto.

Se você precisa atualizar o último commit com alguma outra informação, tenho aqui uma solução simples: git amend (para git commit --amend --no-edit). Este atalho simplesmente adiciona o que estiver no meu index ao último commit, sem mesmo me perguntar se quero modificar a mensagem.

$ git add path/file/new_script.js
$ git amend

Se o commit esta além do último commit, preciso fazer algo mais específico, o que normalmente eu volto N vezes através do comando rebase. Git então abrirá diretamente no meu Vim para me perguntar o que fazer com essa lista de commits. Normalmente edito minhas mensagens de commit e sigo com o rebase até finalizar.

A forma para se fazer rebase em n commits é git rebase -i HEAD~n, mas quem tem tempo para escrever isso? Para isso, criei um atalho simples git rb que aceita um número como argumento:

rb = "!sh -c \"git rebase -i HEAD~$1\" -"

Que me permite utiliza-lo da seguinte maneira:

$ git rb 5

Sim, eu utilizo Vim como editor especialmente para coisas pequenas, mas você pode configurar para usar seu editor de escolha como Sublime ou Visual Studio Code sem muitos problemas. Basta editar o arquivo .gitconfig com algo assim:

[core]
  # Para o Sublime
  editor = subl -n -w

  # Para o VSCode
  editor = code -w

Depois de utilizar o comando git rb, o Vim abrirá com um conteúdo similar a este:

pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit

Aqui você pode utilizar tanto reword quanto edit (ou qualquer outra opção), e quando você salvar suas mudanças (:wq), o rebase vai começar a aplicar as ações em cada commit da lista, e apenas parar naqueles que você modificou a ação. Nesses você pode simplesmente utilizar git rc (para git rebase --continue), até o rebase terminar. Eu também uso atalhos para git rebase --abort com git ra e git rebase --skip com git rs.

A esse ponto, pode ser que você precise atualizar sua branch remota com o novo histórico atualizado, e para isso eu uso o git force que é um atalho para git push --force-with-lease. O argumento --force-with-lease é uma flag muito útil que protege todas as referências remotas que serão atualizadas exigindo que seu valor seja o mesmo que a branch que ja temos armazenados anteriormente. Você pode entender melhor na documentação oficial.

Recapitulando:

$ git rb 5
# Modifique os commits para edição em seu editor;
$ git add path/file/new_script.js
$ git rc
$ git force

Conclusão

Ao longo do tempo que criei vários atalhos que estão me ajudando no meu workflow diário, mas isso poderia virar outro artigo. Para ver todos os que utilizo atualmente, dê uma olhada no meu repositório dotfiles.

E você, quais são os seus truques com Git?

Criando um simples Tabs component em React

Rafaell Lycan — Tue, 24 Jul 2018 00:00:00 +0000

Já faz algum tempo que não falo nada sobre React, e por conta que venho trabalhando tanto com React quanto Angular nos ultimos meses, acho que seria interessante ver como podemos criar composição de componentes utilizando uma estrutura simples a qual ira nos permitir reutilizar-los de maneira simples.

A minha motivação para escrever este artigo foi que em 2 meses, minha equipe e eu reescrevemos nossos componentes que utilizamos em várias aplicações, afim de diminuir a duplicação de código e também para revisarmos as dependências de terceiros de vários projetos que utilizamos atualmente.

Inicialmente utilizávamos muitas dependências do Bootstrap o qual provavelmente foi muito útil no início do projeto. Com o tempo, além de nos custar um pouco de trabalho sobrescrever os estilos dos componentes do Bootstrap, também criávamos outros componentes a partir dos elementos que já existiam.

Além disso, tínhamos (ainda temos) muitos componentes open-source para coisas que não queríamos criar do zero, mas hoje com uma maior maturidade decidimos reescrever algumas partes do software para termos mais controle sobre aquilo que desenvolvemos.

Mantendo a simplicidade

Com objetivo de mostrar como algo simples pode ser feito, vou criar um componente para <Tabs/> que seja flexível para renderizar qualquer jsx como conteúdo da <tab></tab>, e também algo simples que nos proporcionará facilidade para modificação no futuro.

Vamos então desenvolver algo assim:

<Tabs>
    <Tab label={'Tab #1'} className={'tab-custom-class'}>
        <p>content 0</p>
    </Tab>
    <Tab label={'Tab #2'} className={'tab-custom-class'}>
        <CustomComponent propA={'foo'} propB={'bar'} propC={this.handleEvent}/>
    </Tab>
</Tabs>

Como podemos ver, <Tab/> deve renderizar qualquer jsx válido. Isso nos traz a flexibilidade de utilizar propriedades customizadas para outras funcionalidades que sejam úteis no futuro.

O componente

O componente <Tabs/> gerencia seu próprio state e sabe qual conteúdo renderizar baseado na <Tab/> selecionada, sendo assim, ele é quem irá mostrar ou esconder conteúdo. Isso também nos traz a capacidade de renderizar uma tab por padrão quando nenhuma for selecionada através do state interno.

Obs: Você pode encontrar o link com o código e o demo no final deste artigo.

class Tabs extends Component {
  constructor(props) {
    super(props);
    this.state = { activeIndex: props.defaultActiveIndex || 0 };
  }

  handleTabClick = (tabIndex) => {
    if (tabIndex !== this.state.activeIndex) {
      this.setState({ activeIndex: tabIndex });
    }
  }

  cloneTabElement = (tab, index = 0) => {
    const { activeIndex } = this.state;

    return (
      cloneElement(tab, {
        onClick: () => this.handleTabClick(index),
        tabIndex: index,
        isActive: index === activeIndex,
      })
    );
  }

  renderChildrenTabs = () => {
    const { children } = this.props;

    if (!Array.isArray(children)) {
      return this.cloneTabElement(children);
    }

    return children.map(this.cloneTabElement);
  }

  renderChildrenTabs = () => {
    const { children } = this.props;
    const { activeIndex } = this.state;

    if (children[activeIndex]) {
      return children[activeIndex].props.children;
    }

    return children.props.children;
  }

  render() {
    const { className } = this.props;

    return (
      <section className={`tabs ${className}`}>
        <ul className={'tabs__list'}>
          {this.renderChildrenTabs()}
        </ul>
        <div className={'tabs__content'}>
          {this.renderActiveTabContent()}
        </div>
      </section>
    );
  }
};

O componente

O componente <Tab/> é stateless (o que nos permite utilizar um componente funcional), ou seja, o que além de não possuir state, possui o único objetivo de renderizar a tab, permitindo que o desenvolvedor especifique o estilo, e executar uma ação onClick relacionada ao escopo pai (o componente <Tabs/>) quando o evento ocorre.

const Tab = (props) => {

  const { className, label, isActive, onClick } = props;

  const tabClass = `tabs__tab ${className}`;
  const linkClass = isActive ? 'tabs __tab-link--active' : 'tabs__ tab-link';

  return (
    <li className={tabClass}>
      <a className={linkClass} onClick={onClick}>{label}</a>
    </li>
  );
};

Conclusão

Com apenas um pouco de código e ainda sim flexibilidade, criamos um componente <Tabs/> simples, o qual nos permite evoluir-lo se necessário. O código fonte necessário para implementar os componentes podem ser encontrados neste gist, e o pequeno exemplo aqui.

Já implementou algo similar? Você faria algo diferente? Deixe um comentário e vamos aprender juntos :)

Ainda vale a pena aprender PHP?

Rafaell Lycan — Wed, 18 Apr 2018 00:00:00 +0000

Ainda vale a pena aprender PHP?

Com certeza PHP ainda é uma das primeiras linguagens de programação que muita gente, e o motivo deste post é algumas coisas que venho escutando pela internet e depois de ver como o mercado de trabalho internacional.

Ainda que hoje em dia temos hypes e o mundo enterprise sempre cita coisas como Java, C#, NodeJS, etc…, o PHP ainda é uma das linguagens mais utilizadas na web, mesmo contando com diversos websites e lojas virtuais feitos com Wordpress e Magento, ele continua sendo o queridinho de muita gente, inclusive para o mundo das startups.

Bom aqui vai os meus 2 centavos sobre a visão crítica sobre as pessoas que criticam a linguagem.

Ele continua na ativa e resolvendo o problema. Lidem com isso!

Sim, com certeza ainda vale muito a pena e por um bom tempo ainda valerá, e apesar de algumas desvantagens como a tipagem que tem seus pros e contra, possui muito lixo na internet com coisas antigas e tutoriais bobos, e finalmente os haters!

Mas em contrapartida é uma linguagem simples e flexível, pois suporta os paradigmas funcional e OO, não possui tipagem obrigatória além de uma ótima documentação e a comunidade ativa.

Eu particularmente continuo utilizando PHP nos meus projetos paralelos, mesmo gostando muito de NodeJS e Python, e mesmo com muitas criticas sobre ela, os mercados brasileiro e europeu estão procurando por bons desenvolvedores PHP para lidar com aplicações complexas utilizando tecnologias novas, microservicos e muito mais,eu precisava compartilhar com vocês que ele ainda vale a pena, mesmo minha primeira escolha seja JavaScript.

E por onde começar?

Bom, eu gosto de pensar nas coisas de forma simples, uma vez que vocês sabem HTML/CSS e lógica de programação, acho que consigo ver um roadmap em apenas 4 estágios:

0. O Essencial

Antes mesmo de começar a programar PHP, você certamente vai precisar instalar alguma solução AMP (Apache, MySQL, PHP), mas antes disso verifique os seguintes pontos:

O que são servidores web;
O que é HTTP;
Finalmente, instale o PHP;

1. Os Fundamentos

Como em toda linguagem, precisamos entender os fundamentos dela, logo precisamos entender as seguintes partes:

Sintaxe básica;
Declaração de variáveis e constantes;
Tipos de variáveis/dados;
Operadores aritméticos e de atribuição;
Operadores condicionais (IF/ELSE/SWITCH);
Loops (WHILE/FOR/FOREACH);
Arrays (Vetores/Matrizes);
Funções e as Funções nativas da linguagem (seu cinto de utilidades);

2. Web

Não faria sentido estudar PHP até agora sem aprender os benefícios que as linguagens backend nos trazem como:

Requisições GET e POST;
Sessões e Cookies;
Headers do HTTP;
Include e Require;
Variáveis superglobais;
Autenticação;

3. Banco de Dados

Depois de aprender o básico sobre Banco de Dados:

Aprenda SQL (SELECT, INSERT, UPDATE, DELETE, WHERE, OR, ORDER BY, JOIN’s …)
Como se conectar ao MySQL;
PDO Prepared Statements;
Faça um CRUD (Create, Read, Update e Delete)

4. Orientação a Objetos

Se você chegou até aqui e não tem dúvidas sobre as outras 3 fases, parabéns.

Classes vs. Objetos;
Propriedades e Métodos;
Métodos mágicos;
Interfaces, Herança e Polimorfismo
SPL e Design Patterns (Singleton, Factory, GRASP e MVC);

E o que mais?

Sabendo isso você já pode começar a se aventurar no mundo dos CMS’s e se divertir com o Wordpress, aprender um framework como Laravel e muito mais.

Também esta na hora de aprender um pouco mais sobre as PSR’s, Composer, segurança, testes, I/O, webservices e design patterns.

Conclusão

Muitos podem te dizer que existem outras linguagens melhores para se aprender, de fato pode ser verdade ou não, mas ao meu ver, ela é uma linguagem que tem um bom segmento de mercado, então vale muito a pena aprende-la, pois ela pode te ajudar a resolver muitos problemas, os quais outras linguagens seriam como se você tivesse tentando matar uma formiga com uma bazuca.

Então por mais que você já tenhoa uma linguagem principal, você poderia aprende-la como mais uma carta na manga. Assim você terá um diferencial de outros desenvolvedores que insistem em aprender uma linguagem só.

DEV Community: Rafaell Lycan

GraphQL 101: The Basics

Introduction

Fields

Scalar Types

Arguments

Aliases

Fragments

Variables

Directives

Mutations

Pros & Cons

Pros

Cons

Conclusion

Credits

7 Dicas que todo desenvolvedor React deveria saber

1 - Use componentes funcionais.

2 - Mantenha seus componentes pequenos.

3 - Entenda como lidar com this

4 - Use uma função para setState ao invés de um objeto.

5 - Use Prop Types e Default Props sempre que possível.

6 - Utilize React Fragments.

7 - Utilize “React Developer Tools”

Conclusão

As 5 novas features em React 16.6

1 - Memoização com memo

Com classes extendendo Component

Com classes extendendo PureComponent

Com funções (stateless)

✨ Introduzindo memo ✨

2 - Code-Splitting com lazy

⚠️ Alguns pontos importantes

3 - Suspense API

4 - Mais facilidade com contextType

5 - Gerenciando erros com getDerivedStateFromError

Qual é o custo de vida em Barcelona?

Custos de acomodação

Resumindo:

Contas básicas

Alimentação

Lista de preços para produtos populares:

Transporte público

Outros gastos

Conclusão

Como eu uso Git!

Obtendo Informação

Trabalhando com Branches

Trabalhando com Git

Desfazendo seus commits

Rescrevendo seu Histórico

Conclusão

Criando um simples Tabs component em React

Mantendo a simplicidade

O componente

O componente

Conclusão

Ainda vale a pena aprender PHP?

Ainda vale a pena aprender PHP?

E por onde começar?

0. O Essencial

1. Os Fundamentos

2. Web

3. Banco de Dados

4. Orientação a Objetos

E o que mais?

Conclusão

3 - Entenda como lidar com `this`

4 - Use uma função para `setState` ao invés de um objeto.

1 - Memoização com `memo`

Com classes extendendo `Component`

Com classes extendendo `PureComponent`

✨ Introduzindo `memo` ✨

2 - Code-Splitting com `lazy`

4 - Mais facilidade com `contextType`

5 - Gerenciando erros com `getDerivedStateFromError`