pliniohavila / github-blog-challenge Goto Github PK

Para evitar várias requisições para uma API em um componente React, você pode usar o método shouldComponentUpdate do React. Este método permite que você controle se um componente deve ser atualizado ou não quando há mudanças em suas props ou estado.

Por exemplo, você pode usar o shouldComponentUpdate para verificar se o valor da prop que está sendo usada para fazer a requisição para a API realmente mudou antes de fazer a requisição. Se o valor da prop não mudou, o componente não será atualizado e, consequentemente, a requisição para a API não será feita.

Aqui está um exemplo de como você pode usar o shouldComponentUpdate para evitar várias requisições para uma API em um componente React:

class MyComponent extends React.Component {
  shouldComponentUpdate(nextProps) {
    // Verifique se o valor da prop que está sendo usada para fazer a requisição para a API mudou
    return this.props.value !== nextProps.value;
  }

  render() {
    // Faça a requisição para a API aqui, usando o valor da prop para determinar o que buscar
  }
}

Lembre-se de que o shouldComponentUpdate deve ser usado com cuidado, pois pode afetar o desempenho do seu aplicativo se usado de forma inadequada. É importante fazer testes e medir o desempenho do seu aplicativo para garantir que o uso do shouldComponentUpdate não está causando problemas.

Para evitar várias requisições para uma API em um componente React funcional, você pode usar o hook useEffect do React. O useEffect permite que você execute uma determinada ação quando há mudanças em determinadas propriedades ou estado do seu componente.

Por exemplo, você pode usar o useEffect para verificar se o valor da prop que está sendo usada para fazer a requisição para a API realmente mudou antes de fazer a requisição. Se o valor da prop não mudou, o efeito não será executado e, consequentemente, a requisição para a API não será feita.

Aqui está um exemplo de como você pode usar o useEffect para evitar várias requisições para uma API em um componente React funcional:

function MyComponent(props) {
  // Use o useEffect para executar uma determinada ação quando há mudanças na prop que está sendo usada para fazer a requisição para a API
  useEffect(() => {
    // Faça a requisição para a API aqui, usando o valor da prop para determinar o que buscar
  }, [props.value]);

  return (
    // O conteúdo do seu componente vai aqui
  );
}

Lembre-se de que o useEffect deve ser usado com cuidado, pois pode afetar o desempenho do seu aplicativo se usado de forma inadequada. É importante fazer testes e medir o desempenho do seu aplicativo para garantir que o uso do useEffect não está causando problemas.

O hook useCallback do React é um hook que permite que você armazene em cache uma função e retorne sempre a mesma instância da função quando suas dependências não mudam. Isso pode ser útil em casos em que você tem um componente que é renderizado frequentemente e que precisa passar uma função como prop para um filho.

Por exemplo, suponha que você tenha um componente MyParent que é renderizado várias vezes e que possui um filho chamado MyChild. O MyChild precisa de uma função onClick como prop, mas cada vez que o MyParent é renderizado, uma nova instância da função onClick é criada e passada para o MyChild. Isso pode causar problemas de desempenho, pois o MyChild será atualizado várias vezes mesmo que a função onClick não tenha mudado.

Para resolver esse problema, você pode usar o useCallback para armazenar em cache a função onClick e garantir que sempre seja passada a mesma instância para o MyChild quando as suas dependências não mudam. Aqui está um exemplo de como você pode fazer isso:

function MyParent() {
  // Armazene a função onClick em cache com o useCallback
  const onClick = useCallback(() => {
    // O código da sua função vai aqui
  }, []);

  return (
    <MyChild onClick={onClick} />
  );
}

Com o useCallback, a função onClick só será recriada quando as suas dependências mudarem. Isso garante que o MyChild só será atualizado quando a função onClick realmente mudar, o que pode melhorar o desempenho do seu aplicativo.

Se te contasse, teria que te matar. Brincadeira!
Mais seriamente:
Tudo pode ser feito com hashmaps.
Os gerentes sempre mentem. Esse sistema importante, que precisa estar pronto para ontem, não será analisado até dois meses após a entrega.
É muito melhor escrever algo "certo" do que fazer-o rápido e com bugs. Sempre que sinta que tem que se apressar, não o faça. Faça como se tivesse todo o tempo do mundo. Sempre faça a coisa certa. Levará muito menos tempo para terminar e você se sentirá muito melhor respeito ao código.
Se eles disserem: "Não temos mais dinheiro, termine". Então reduza o alcance, remova funcionalidades, faça menos, use metodologias topo agile, mas nunca se apresse.
O efeito GIGO (do inglês:Garbage in, garbage out): Se entra lixo sairá lixo. Certifique-se de que os requisitos são os corretos.
Não há funcionalidades sem documentação. Ou as documenta, ou ninguém saberá que eles existem.
RTFM( Do ingles: Read the Fucking Manual, ou Lê a porcaria do manual) é má educação. A usabilidade do corredor (Hallway usability) é muito melhor. Você pode achar que isto contradiz o número 5, quizas sim ou quizas não. [[ De fato este é o principal motivo pelo qual o Windows venceu o Unix na área de trabalho. Unix e Linux estavam mais preocupados com os manuais e com a educação dos seus usuários enquanto o Windows se preocupou com a reação imediata deles. Ou seja, eles preferiram se livrar dos manuais e permitiram que as pessoas se focassem no que realmente queriam fazer. Eu nunca vi um manual para o iPhone ou para um dispositivos Android, até uma criança de 3 anos pode usá-lo. Existe uma lição para aprender aqui, mas duvido que internamente Microsoft, Apple e Google não documentem a funcionalidade e o "como as coisas são feitas", trabalhei para a Microsoft e tudo sempre foi documentado, o estilo sempre foi "meia página", o mais direto e claro possível. Os gerentes de programa eram responsáveis ​​pela análise comparativa com outros produtos e concorrentes, e os documentos eram sempre grandes, mas o estilo era o mesmo. ]]
Você aprende muito mais quando observa as pessoas usando o seu sistema. Monitore o uso e corrija-o conforme seja necessário. [Deixa-me contar uma breve história. Vinte anos atrás eu desenvolvi um sistema para alguns jovens, vamos chamá-los de secretários, que eta para armazenar e pesquisar informações sobre os pacientes. Acontece que algumas das informações foram alteradas, algumas foram excluídas e eles não estavam usando suas respectivas contas, pelo que se culpavam mutuamente. Eu troquei todas as suas senhas e gravei todas as ações numa tabela de banco de dados usada para isso. O problema aconteceu de novo e eu voltei para a minha mesa e antes de a discussão terminar apontei para uma das meninas e disse: você fez isso, neste dia, neste momento. Nunca tivemos esse problema novamente. ]
O teste de unidade é muito mais eficaz que o QA tradicional. Use ambos no começo. Testes unitários são PRIMEIRO (Unit Tests Are FIRST) [ O objetivo de fazer testes unitários automatizados é que você nunca mais precisará usar o debugger (uma vez ao ano, tudo bem, especialmente se você precisar depurar seus testes). Escrevendo Grandes Testes Unitários: Melhores e Piores Práticas (Writing Great Unit Tests: Best and Worst Practices), mas ao contrário da crença popular, você deve atacar de coisas internas no sistema, esta bem testar o banco de dados para atacar sistemas externos, mas não internos, então de certo modo um teste unitário é também um teste de integração interna. Mas você também deve usar seus mesmos testes de unidade como testes de integração, invertendo um switch. A regra geral para testes unitários é "testar tudo o que pode falhar". As 12 melhores práticas de teste de unidades selecionadas - Doces de engenharia de software (SW Engineering Candies - Top 12 Selected Unit Testing Best Practices) E como algumas pessoas recomendam usar uma assert por método de teste, isso significa que se 10 coisas falharem, você precisará escrever 10 métodos de teste, e todos terão a mesma aparência, o próximo terá apenas mais uma linha do que a anterior. Qual é o propósito disso? Você vê um teste falhar e você não precisa depurá-lo, você não precisa olhar para o código de teste, você vê o nome do teste e sabe exatamente o que falhou. Isso aumenta a produtividade 10x.]
A programação funcional é a onda do futuro. Aprenda Haskell.
Para estimativa, use estimativas de projetos anteriores corrigidas por dados reais. Você precisa de dados concretos para isso: use o número de telas, tabelas de banco de dados, casos de uso, etc.
O controle de versão é seu amigo.
O código deve ser DRY em vez de WET. [[DRY significa Don't Repeat Yourself, isso significa remover código duplicado, porque o código repetido é um pesadelo de manutenção, quando você precisa corrigir bugs, você precisa procurar por todo o código repetido, e se você trabalha com mais pessoas, eles irão copiar e colar mais rápido do que você pode resolver os bugs. WET significa Write Everything Twice e seu primo feio Write Every Time, significando exatamente o oposto de DRY: muitos e muitos códigos repetidos.]]
Cache de algoritmos alheios.
Os riscos técnicos são controlados usando protótipos.
Como todos os problemas técnicos podem ser resolvidos, todos os problemas do projeto reduzem-se a problemas organizacionais. É por isso que todas as metodologias agiles existem: para lidar com problemas organizacionais. A chave para o sucesso é "falhar rápido".
16. Anote a retrospectiva da iteração e aja de acordo com ela.
Anote e numere todos os requisitos. Use a depuração de requisitos do DSDM. Anote e numere todas as decisões de projeto usadas para resolver conceitualmente todos os requisitos. Crie protótipos para cada decisão de projeto.
Entre em uma academia e vá todos os dias. Até 10 minutos de exercícios leves farão você se sentir melhor.
Certifique-se de que seu código seja executado em sistemas operacionais diferentes e em bancos de dados diferentes. Use integração contínua para isso.
Você não está sendo pago para escrever código, você é pago para escrever funcionalidade. Código é apenas custo. Há custo para criá-lo, custo para depuração, custo para auditoria, custo de armazenamento, custo para manutenção etc.

Fonte: Quora

O CORS (Cross-origin Resource Sharing) é um protocolo que os navegadores utilizam para acessar/compartilhar recursos de diferentes origens.

Ele atua por meio de cabeçalhos HTTP específicos. Por meio desses, permite-se que a origem da requisição acesse os recursos em outra origem.

Caso não tenha esses cabeçalhos, a solicitação de um recurso que tenha uma origem diferente (domínio, protocolo e porta) da sua própria origem será negado.

Um exemplo de requisição cross-origin: quando o front-end - example.com - de uma aplicação faz uma requisição para uma API em - api.com -.

­• Requisições CORS HTTP

Inicialmente é feita uma requisição CORS-preflight, que verifica se o protocolo CORS é suportado. No qual utiliza o método “OPTIONS” que inclui cabeçalhos especiais do CORS:

Origin – a origem da fonte;
Access-Control-Request-Method – indica o método da futura requisição;
Access-Control-Request-Headers – indica os cabeçalhos da futura requisição;

­• Respostas CORS HTTP

Além do status 200 ok.

Access-Control-Allow-Origin: indica se o recurso pode ser compartilhado;
Access-Control-Allow-Credentials: indica se é necessário credenciais;
Access-Control-Allow-Methods: quais métodos são aceitos;
Access-Control-Allow-Headers: Indica quais cabeçalhos são suportados pela URL de resposta para os propósitos do protocolo;
Access-Control-Max-Age: informa o número de segundos - padrão: 5 - que as informações fornecidas pelos cabeçalhos "Acess-Control-Allow-Methods" e "Acess-Control-Allow-Headers" podem cacheadas.
Access-Control-Expose-Headers: lista quais cabeçalhos podem serem expostos na resposta.

­• Requisição principal

Se tudo correu bem (com a requisição CORS-preflight), o caminho está disponível para a realização da requisição principal, ora pretendida.

Uma nota final. A requisição CORS-preflight é invisível para o JavaScript. Quando utilizamos, por exemplo, a API Fecth, é obtido apenas a resposta da requisição principal ou um erro, caso não tenha permissão.

Imagem representada de uma requisição com o protocolo CORS.

fontes:
https://pt.wikipedia.org/wiki/Cross-origin_resource_sharing
https://fetch.spec.whatwg.org/#http-cors-protocol
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/CORS
https://www.treinaweb.com.br/blog/o-que-e-cors-e-como-resolver-os-principais-erros
https://javascript.info/fetch-crossorigin