CONV 2. BATCH

Após o usuário escolher ir ao carrinho, a aplicação navega até a pilha de Checkout. Nesta pilha, as telas são componentes React que foram separados em arquivos com os mesmos nomes dos components: Cart.js e SelectPaymentMethod.js, como mostrados na figura 18.

Figura 18 – Pilha de navegação de realização do pedido: carrinho e seleção de pagamento Fonte – Própria

A primeira tela desta pilha a ser mostrada ao usuário é a tela Cart, cujo arquivo de extensão JS possui o mesmo nome. Quando este componente React é montado o primeiro método chamado é a Função de Ciclo de vida componentDidMount, executada automaticamente pelo React. Dentro deste método, duas ações ocorrem: o componente passa a ser ouvinte de um evento, e chama o método _componentDidFocus quando ele ocorre, e o método assíncrono _validateCart é chamado.

O evento a qual o componente é assinalado como ouvinte é o didFocus (focou, em tradução livre). Este é o evento de quando a tela está em foco, isto é, é a tela que está sendo mostrada ao usuário naquele momento. O método _componentDidFocus implemen- tado neste trabalho tem uma única função: chamar o método assíncrono _validateCart, responsável por fazer uma requisição HTTP POST, com o seu corpo em formato JSON, com o atual estado do carrinho para a API. Ou seja, toda vez que o usuário coloca a tela

Cart em foco, o método _validateCart é invocado.

Este é o método responsável por validar o carrinho do usuário. Nesta implementação, uma escolha foi tomada para melhorar a experiência do usuário: o carrinho não é persistido na API. Isto é, o carrinho é uma entidade efêmera, em memória, na aplicação cliente. O motivo desta decisão é simples: evitar a necessidade de fazer chamadas à API todas as vezes que carrinho sofresse qualquer alteração. Ou seja, toda vez que o usuário necessitasse alterar uma quantidade de um produto, uma nova requisição deveria ser feita, deixando cada iteração do usuário cada vez mais lenta. E, ao invés disso, a validação do carrinho é chamada quando a tela está em foco. A validação do carrinho checa as seguintes regras de negócio:

1. Preço de entrega: checa se o preço da entrega que o usuário possui no carrinho em memória é o mesmo que está na API;

2. Preço das variantes de produto: checa se o preço das variantes de produto que o usuário possui no carrinho em memória é o mesmo que está na API;

3. Disponibilidade do produto: checa se as variantes de produto que o usuário possui no carrinho em memória estão disponíveis na API;

4. Disponibilidade do lojista para o endereço selecionado: checa se o lojista selecionado está entregando no endereço selecionado pelo usuário.

Com estas regras de negócio satisfeitas, o usuário pode, enfim, finalizar o seu pedido. Ainda na tela Cart, o usuário pressiona um botão que invoca a função assíncrona

_placeOrder. Esta função faz uma requisição HTTP POST para a API, com o seu corpo em

formato JSON, com as informações do carrinho. A API valida as informações novamente, com as mesmas regras de negócio da validação do carrinho, e responde com um código HTTP 201, caso o pedido tenha sido criado, ou um código HTTP 400 caso alguma validação tenha falhado. Em caso de erro, o usuário recebe um alerta com as mensagens de erro das validações e em caso de sucesso, o usuário é redirecionado para página de pedidos ativos, na Order Stack (pilha de pedidos, em tradução livre).

3.3.2.3 Order Stack: o acompanhamento dos pedidos

Após o usuário realizar o pedido, a aplicação navega até a pilha de pedidos. Nesta pilha, as telas são componentes React que foram separados em arquivos com os mesmos nomes dos components: ActiveOrders.js, OrderHistory.js e OrderDetails.js, como mostrados na figura 19.

Figura 19 – Pilha de navegação do acompanhamento de pedidos Fonte – Própria

Nesta pilha, a primeira tela a ser mostrada é a ActiveOrders, cujo arquivo de extensão JS possui o mesmo nome. Quando este componente React é montado o primeiro método chamado é a Função de Ciclo de vida componentDidMount, executada automaticamente

pelo React. Dentro dele, o método assíncrono _fetchDataAsync é chamado com o objetivo de requisitar os pedidos ativos do usuário autenticado. Como mencionado na seção 3.1.4, cada pedido possui um status do tipo inteiro. Nesta implementação, cada pedido tem os seguintes estados:

1. Aguardando Confirmação: quando um pedido é criado corretamente e está aguar- dando confirmação do parte do lojista;

2. Pagamento Pendente: quando um pedido é criado corretamente, com o pagamento online selecionado mas ainda não verificado;

3. Pedido Confirmado: quando um pedido criado corretamente, que estava aguar- dando confirmação é confirmado pelo lojista. Isto significa que o lojista irá entregar os produtos requisitados pelo usuário;

4. Saiu para Entrega: quando um pedido que foi confirmado pelo lojista é despachado por ele para que seja entregue ao usuário;

5. Pedido finalizado: quando um pedido despachado pelo lojista é recebido pelo usuário corretamente;

6. Pedido cancelado: quando um pedido não pôde ser finalizado por algum motivo. Por exemplo: falta de estoque, indisponibilidade do motoqueiro, recusa de recebimento por parte do cliente, fim do horário de entrega, dentre outros.

Entende-se como pedido ativo, qualquer pedido que tenha um status diferente de 5 ou 4 (Pedido cancelado, ou Pedido finalizado, respectivamente. E são estes os pedidos retornados pela API, em formato JSON, na chamada do método _fetchDataAsync. Este mesmo método é responsável por atualizar o estado do componente com a lista retornada pelo servidor. Nest momento, o React invoca o método render. Por consequência, como mencionado na seção acima, a função render deste componente é chamada e as informações são mostradas ao usuário no formato de uma interface amigável a seres humanos.

Ainda nesta pilha de navegação, o usuário autenticado pode escolher ver o seu hatórico de pedidos. Quando realizada tal ação, a aplicação navega até a tela OrderHistory cujo arquivo de extensão JS possui o mesmo nome. Quando este componente React é montado o primeiro método chamado é a Função de Ciclo de vida componentDidMount, executada automaticamente pelo React. Dentro dele, o método assíncrono _fetchDataAsync é chamado com o objetivo de requisitar à API, através de uma requisição HTTP GET, os dados dos pedidos finalizados ou cancelados, isto é, pedidos cujo status sejam 5 ou 4. Ao receber os dados, em formato JSON, o componente atualiza o seu estado com as informações recebidas. Por consequência, como mencionado na seção acima, a função

render deste componente é chamada e a lista é mostrada ao usuário no formato de uma

interface amigável a seres humanos.

Em qualquer uma das duas listas: pedidos ativos ou histórico pedidos, o usuário pode selecionar um para ver os detalhes daquele pedido. Quando tal ação acontece, a aplicação navega até a tela OrderDetails cujo arquivo de extensão JS possui o mesmo nome. Quando este componente React é montado o primeiro método chamado é a Função de Ciclo de vida componentDidMount, executada automaticamente pelo React. Dentro dele, o método assíncrono _fetchDataAsync é chamado com o objetivo de requisitar à API, através de uma requisição HTTP GET, os dados do pedido selecionado. Ao receber os dados, em formato JSON, o componente atualiza o seu estado com as informações recebidas. Por consequência, como mencionado na seção acima, a função render deste componente é chamada e os detalhes do pedido selecionado são mostrados ao usuário no formato de uma interface amigável a seres humanos. Estes detalhes incluem: loja a qual o pedido foi feito, itens do pedido, valor de entrega, valor total, forma de pagamento, estado atual do pedido e endereço de entrega.