Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

1
resposta

slug

uau, slug, para identificar um objeto, que interessante, até onde eu estudei nesta trilha eu identificava tudo com ID ou index, mas claro que eu to bem confuso agora, eu nao acompanhei a criação desse data.js

1 resposta

Antes de comparar os três, vale separar uma coisa: eles não estão no mesmo plano.

index é posição no array. Vem do JavaScript, o map (e outros métodos de arrays, como o forEach) te entrega.

id e slug são propriedades dentro do objeto. Alguém escreveu elas ali, à mão, no data.js. Não são recurso do React nem da linguagem — são nomes de campo, como title e cover. Se o arquivo chamasse codigo e endereco, funcionaria igual.

Feita essa separação, cada um serve pra uma coisa.

index

Posição no array naquele momento. Só isso.

Serve pra percorrer a lista. Não serve pra identificar, porque ele muda: remove um item do meio e todo mundo atrás anda uma casa.

Isso importa direto no React, no key:

{eventos.map(function (evento, indice) {
  return <CardEvento evento={evento} key={indice} />
})}

Funciona enquanto a lista só cresce no final. No dia em que ela reordena, filtra ou remove do meio, o React se perde — ele usa a key pra saber qual elemento é qual entre uma renderização e outra. Se a key de um item muda, pra ele virou outro item.

Por isso key pede algo estável, que ande junto com o dado.

id

Identificador do registro. Nasce com o dado e não muda.

É o que resolve o problema do key:

{posts.map(function (post) {
  return <PostCard post={post} key={post.id} />
})}

Agora pode reordenar, filtrar, remover. Cada card continua sendo ele mesmo.

E é também o que liga um dado no outro. Repara nos comentários do data.js: cada um guarda authorId. É assim que o comentário aponta pro autor.

slug

Slug é termo comum de web, não coisa de React. Você já viu um monte deles sem saber o nome — é o pedaço legível que aparece na barra de endereço.

Compara:

/posts/5
/posts/introducao-ao-typescript

A segunda diz pra pessoa o que tem ali antes de clicar. Funciona melhor em busca, faz sentido quando alguém manda o link no WhatsApp, e não expõe a numeração interna dos dados.

Por isso ele vem sempre em minúsculo, sem acento e com hífen: precisa sobreviver a uma barra de endereço.

E, de novo: no data.js ele é só uma string dentro do objeto. Vira endereço quando a navegação entrar no projeto e alguém usar ele pra isso.

Comparando

O que éMuda?
indexposição no array, vem do mapsim, a qualquer mexida na lista
idcampo do objeto, identifica o dadonão
slugcampo do objeto, texto pra usar na URLnão

Os três juntos não é redundância. É cada um no seu trabalho.

Sobre o data.js

Ele não é construído em aula porque não é conteúdo do projeto. É um mock: dados no mesmo formato que a API vai devolver mais pra frente, escritos à mão pra gente conseguir montar a tela antes do back-end existir.

Ou seja, é temporário e é combinado. Os campos estão ali porque alguém decidiu que iam estar.

E isso não é só coisa de curso. Na real você recebe o contrato de dados pronto — de um back-end, de um serviço de terceiro, de um CMS — e o teu trabalho começa em cima dele, não antes. Abrir um arquivo de dados que você não escreveu e entender o formato é rotina.

Qualquer campo desse arquivo que você quiser entender, é só perguntar aqui.