Criando uma Rede Social

Índice

• 1. Prefácio
• 2. Resumo do projeto
• 3. Objetivos de aprendizagem
• 4. Considerações gerais
• 5. Critérios de aceitação mínimos do projeto
• 6. Hacker edition
• 7. Entrega
• 8. Guias, dicas e leituras complementares

---

1. Prefácio

Instagram, Snapchat, Twitter, Facebook, Twitch, Linkedin, etc. As redes sociais invadiram nossas vidas. Nós as amamos ou odiamos, e muitas pessoas não conseguem viver sem elas.

Há redes sociais de todo tipo para todos os tipos de interesse. Por exemplo: em uma rodada de financiamento com investidores, foi apresentada uma rede social para químicos onde os usuários podem publicar artigos a respeito de suas pesquisas, comentar os artigos de seus colegas e filtrar artigos de acordo com determinadas tags ou popularidade, mais recente ou mais comentado.

2. Resumo do projeto

Neste projeto você construirá uma Rede Social sobre o que você e sua equipe decidirem. Pode ser, por exemplo, sobre alimentação saudável, feminismo, educação, saúde, energias renováveis, amantes das Empanadas, de Tacos, de Feijoada, ou do que seja.

Sua Rede Social terá que permitir à qualquer usuário criar uma conta de acesso, logar-se com ela, criar, editar, deletar e dar likes em publicações.

3. Objetivos de aprendizagem

O objetivo principal de aprendizagem deste projeto é construir uma Single-page Application (SPA) responsiva (com mais de uma tela/ página) na qual seja possível ler e escrever dados.

HTML e CSS

• HTML semântico
• CSS flexbox
• Construir sua aplicação respeitando o protótipo.

DOM e Web APIs

• Manipulação do DOM
• History API

Javascript

• Uso de callbacks
• Consumo de Promises
• Uso de ES modules (import | export)

Firebase

• Firestore
• Firebase Auth
• Firebase security rules

Testing

• Teste unitários
• Testes assíncronos
• Mocking

Git e Github

• Colaboração pelo Github
• Organização pelo Github Projects

Boas práticas de programação

• Modularização
• Nomenclatura / Semântica
• Linting

---

4. Considerações gerais

• Este projeto deve ser desenvolvido em trios.

• A lógica do projeto deve estar implementada completamente em JavaScript (ES6+), HTML e CSS 😃. Para este projeto não está permitido o uso de frameworks ou bibliotecas de CSS e JS.

• A divisão e organização do trabalho deve permitir, sem exceção, que cada integrante da equipe pratique a aprendizagem de tudo que está envolvido em cada história. Não dividam o trabalho como em uma fábrica.

• Está avançando em seus projetos com alguma fluidez e sem grandes problemas? Seja generosa com suas parceiras, deixe-as aprender e praticar sem restrições, mesmo que demore um pouco mais. Aproveite para mentorá-las, para fazer pair programming. Uma das melhores formas de aprender é explicar verbalmente.

• Está sentindo dificuldade e para você é mais difícil de avançar? Não fique com as partes "fáceis" do projeto. Converse, negocie, busque sua oportunidade de praticar e aprender o que é mais difícil para você.

• Vocês apenas poderão trabalhar em uma história por vez. Não avancem para a próxima sem completar a anterior. As histórias apenas são concluídas quando se completam todos os critérios de aceitação + toda sua definição de pronto.

5. Critérios de aceitação mínimos do projeto

5.1 Boilerplate

O boilerplate contém uma estrutura de arquivos como ponto de partida, assim como toda a configuração de dependências:

.
├── src
|  ├── pages (páginas)
|  |  └── home
|  |  |  ├── index.js
|  |  |  └── index.spec.js
|  |  └── login
|  |     ├── index.js
|  |     └── index.spec.js
|  ├── services (serviços externos)
|  |  ├── index.js
|  |  └── index.spec.js
|  ├── utils
|  |  └── history.js
|  ├── index.html
|  ├── router.js
|  └── style.css
├── README.md
└── package.json

src/index.html

O arquivo index.html é a página que vai ser exibida ao usuário.

src/router.js

O script de index.html aponta para este arquivo router.js, que cuida de direcionar as rotas da aplicação sem a necessidade de um novo carregamento da página.

Temos a importação das páginas Home e Login como exemplo, e também da função onNavigate que registra cada tela adicionada ao histórico de navegação.

A função renderRouter presente neste arquivo é responsável por renderizar as página da aplicação (Home e Login) e é acionada em dois momentos distintos:

• load: quando há o carregamento inicial da página. Ex: ao acessar localhost:5000 a página Home é renderizada dentro da div#root dentro do index.html, ou

• popstate: quando há o carregamento da página já contendo a rota desejada. Ex: ao acessar localhost:5000/login a página Login é renderizada dentro da div#root dentro do index.html.

A função onNavigate() está sendo disparada quando há um click em qualquer uma das rotas presentes nesse boilerplate.

src/utils/history.js

Este arquivo contém a função onNavigate(), que recebe como parâmetro path e state, que são armazenados no histórico do navegador. Dessa forma, mesmo sem recarregar a página (por ser SPA), se torna possível navegar entre todas páginas renderizadas por meio do botão de back e forward do navegador. History API

src/services/index.js

A manipulação de dados dependerá do servidor externo Firebase.

Recomendamos que este arquivo contenha todas as funcionalidades (suas funções) que correspondam a qualquer manipulação de dados (criar, ler, atualizar, deletar).

src/pages

Neste diretório estão as pastas home e login, e cada uma delas contém um arquivo index.js. Sugerimos que o conteúdo de cada página fique separado de acordo com o exemplo proposto, em forma de funções que retornam o conteúdo HTML desejado. Dessa maneira, a responsabilidade de cada página fica isolada.

src/**/**/*.spec.js

Todos os arquivos com terminação .spec.js são lidos e executados com o comando npm run test. Como temos diversas funcionalidades distribuídas na aplicação, optamos por deixar os arquivos de teste próximos às funcionalidades testadas.

5.2 Definição do produto

No README.md, conte-nos brevemente como você mapeou as necessidades dos seus usuários e como você chegou à definição final do seu produto. É importante que detalhe:

• Quem são os principais usuários do produto.
• Qual problema o produto resolve/para que ele serve para esses usuários.

5.3 Histórias de usuário

Depois de entender as necessidades de seus usuários, escreva as Histórias de Usuário. Elas representam tudo o que ele precisa fazer/ver na Rede Social. Cada uma de suas histórias de usuário deve possuir:

• Critérios de aceitação: tudo o que deve acontecer para satisfazer as necessidades do usuário.

• Definição de pronto: todos os aspectos técnicos que devem ser atendidos para que, como equipe, saibam que essa história está finalizada e pronta para ser publicada. Todas suas histórias de usuário (com exceções), devem incluir esses aspectos em sua definição de pronto (além de tudo o que precisa adicionar):

  • Ser uma SPA.
  • Ser responsivo.
  • Receber code review de pelo menos uma parceira de sua equipe.
  • Fazer tests unitários.
  • Fazer testes manuais buscando erros e imperfeições simples.
  • Fazer testes de usabilidade e incorporar o feedback dos usuários como melhorias.

5.4 Desenho da Interface de Usuário (protótipo de baixa fidelidade)

Você deve definir qual será o fluxo que o usuário seguirá dentro do seu aplicativo e, com isso, criar a interface do usuário (UI) que siga este fluxo.

5.5 Responsivo

Deve funcionar bem em dispositivos de tela grande (computadores, laptops etc.) e pequena (tablets, telefones celulares etc.). Sugerimos seguir a técnica mobile first (mais detalhes sobre essa técnica ao final).

5.6 Considerações sobre o comportamento da Interface do Usuário (UI)

Essas considerações ajudarão você a escrever as definições de pronto de sua H.U.:

Criação e login de conta de usuário

• Login com Firebase:
  • Para o login e postagens na timeline, você pode usar Firebase Authentication e Cloud Firestore
  • O usuário deve poder criar uma conta de acesso ou autenticar-se com conta de e-mail e senha e também com uma conta do Google.
• Validações:
  • Somente usuários com contas válidas têm acesso permitido.
  • Não haver usuários repetidos.
  • A conta do usuário deve ser um email válido.
  • O que o usuário digita no campo de senha (input) deve ser secreto.
• Comportamento:
  • Quando o formulário de registro ou login é enviado, ele deve ser validado.
  • Se houver erros, mensagens descritivas devem ser exibidas para ajudar o usuário.

Timeline/linha do tempo

• Validações:
  • Ao publicar, deve ser validado se há conteúdo no input.
• Comportamento:
  • Ao recarregar o aplicativo, é necessário verificar se o usuário está logado antes de exibir o conteúdo,
  • Conseguir publicar um post.
  • Poder dar e remover likes em uma publicação. Máximo de um por usuário.
  • Visualizar contagem de likes.
  • Poder excluir uma postagem específica.
  • Solicitar confirmação antes de excluir um post.
  • Ao clicar em editar um post, você deve alterar o texto para um input que permite editar o texto e salvar as alterações.
  • Ao salvar as alterações, você deve voltar ao texto normal, mas com a informação editada.
  • Ao recarregar a página, poder ver os textos editados.

5.7 Considerações técnicas sobre front-end

• Separar a manipulação do DOM da lógica (separação de responsabilidades).
• Ter várias telas. Para isso, seu aplicativo deve ser um Single Page Application (SPA)
• Alterar e persistir dados. Os dados que você adiciona ou modifica devem persistir por todo o aplicativo. Recomendamos que você use o Firebase para isso também.

Testes unitários

• Lembre-se de que não há setup de testes definido, isso dependerá da estrutura do seu projeto. Você não deve esquecer de pensar sobre os testes. Eles podem ajudar a definir a estrutura e sua lógica.

• Os testes de unidade devem cobrir no mínimo 70% de statements, functions, lines e branches.

5.8 Considerações técnicas UX

• Faça pelo menos 2 entrevistas com os usuários.
• Faça um protótipo de baixa fidelidade.
• Verifique se a implementação do código segue as diretrizes do protótipo.
• Faça sessões de teste de usabilidade com o produto em HTML.

6. Hacker Edition

As seções chamadas Hacker Edition são opcionais. Se você terminou e cumpriu todos os requisitos acima e sobrou tempo, tente concluí-las. Dessa forma, você pode aprofundar e/ou exercitar mais os objetivos de aprendizagem do projeto.

• Criar posts com imagens.
• Procurar usuários, adicionar e excluir "amigos".
• Definir a privacidade de posts (público ou apenas para amigos).
• Permitir ver na linha do tempo de usuários "não amigos" apenas os posts públicos.
• Permitir comentar ou responder a uma postagem.
• Editar perfil.

7. Entrega

O projeto será entregue subindo seu código no GitHub (commit /push) e a interface será hospedada usando o Firebase Hosting.

---

8. Guias, dicas e leituras complementares

Primeiros passos

Para começar, você precisará criar um fork e clone deste repositório.

Instalação de Firebase

Este projeto está configurado para rodar por meio do servidor do Firebase. Para isso, será necessário possuir o Firebase CLI instalado globalmente em sua máquina. Utilize o comando npm install -g firebase-tools

Inicie um novo projeto web no console do Firebase (pode desabilitar o analytics).

Caso apareça a opção de habilitar o Hosting na tela seguinte, selecionar.

Clique no menu lateral Cloud Firestore para criar uma nova database como production mode e escolher a região us-east1.

IMPORTANTE rodar todos os comandos do Firebase no terminal a partir da pasta raiz do projeto.

Executar o comando firebase login e realizar o login por meio de uma conta Google - deve abrir uma janela automaticamente, se não abrir pode clicar no link que vai aparecer no console.

Executar o comando firebase init para iniciar o setup do projeto.

Selecionar Hosting (aperte espaço para selecionar essa opção e depois enter).

Selecionar Use an existing project (o terminal vai mostrar o nome do projeto que você acabou de criar no site do Firebase).

Escrever src para definir como public directory (o padrão vai estar como public).

Escrever y para selecionar como SPA.

Escrever N para não fazer builds e deploys automáticos com GitHub.

O Firebase vai dizer que src/index.html já existe e pergunta se quer sobrescrever. Nesse momento não tem problema fazer isso, ele vai sobrescrever o que veio no boilerplate da Lab com uma página padrão do Firebase. Sugerimos dar N, para não sobrescrever o index.html.

Se der tudo certo, o Firebase vai criar o arquivo .firebaserc de configuração na pasta do projeto e estamos prontas pra continuar.

Instale as dependências do projeto rodando o comando npm install.

Para iniciar sua aplicação web, use o comando npm start que usamos nos projetos anteriores. Com esse comando, você deve ver em http://localhost:5000 uma página padrão do Firebase, que está sendo renderizada de src/index.html.

Mobile first

O conceito de mobile first faz referência a um processo de desenho e desenvolvimento que parte de como se vê e como funciona uma aplicação primeiro em um dispositivo móvel e mais adiante se analisa como adaptar a aplicação à telas progressivamente maiores. Esta é uma contraposição ao modelo tradicional, no qual primeiro se desenha os websites (ou webapps) para desktops e depois os adaptam para telas menores.

A motivação aqui é se assegurar que desde o começo sejam desenhadas telas responsivas. Dessa forma, começamos com a aparência e o comportamento do aplicativo em uma tela e ambiente móvel.

Múltiplas telas

Em projetos anteriores, nossas aplicações eram compostas de apenas uma tela principal (uma só página). Neste projeto, precisaremos dividir nossa interface em várias pages e oferecer uma maneira de navegar entre essas telas. Esse problema pode ser resolvido de várias maneiras: com arquivos HTML independentes (cada um com seu próprio URL) e links tradicionais; mantendo na memória e renderizando condicionalmente (sem atualizar a página); manipulando o histórico do navegador com window.history. Neste projeto, convidamos você a explorar opções e decidir sobre uma opção de implementação.

Gravação de dados

Nos projetos anteriores, consumimos dados, mas ainda não tínhamos escrito dados (salvar alterações, criar dados, excluir, etc). Neste projeto, você precisará criar (salvar) novos dados, além de ler, atualizar e modificar os dados existentes. Esses dados podem ser salvos remotamente usando o Firebase.

Outras:

• Mobile First
• Mobile First Is NOT Mobile Only - Nielsen Norman Group
• Flexbox - CSS Tricks
• Módulos: Export
• Módulos: Import