key값에 index를 써도 되는 경우와 쓰지 말아야 하는 경우

[wmakerjun]

state flow down, li key값을 index로 하는게 순서가 보장되지 않아서 위험 할 수 있다는 건 이해했는데, 로또 목록을 보여줄때에는 수정 삭제가 일어나지 않아서 이 때에도 index를 키값으로 이용하는 것이 안티패턴인가 하는 것.

[365kim]

리뷰어님으로부터 피드백을 받으면서 정리했던 내용 공유합니다!

이터러블의 key값

리액트에서 리스트를 만들 때 고유한 key를 설정하도록 강제하는 이유는 배열의 요소 추가, 수정, 삭제에 효율적으로 대응하기 위함으로 알고 있습니다.

• 효율성 측면
  • 예시: [a b c] 리스트에서 a를 삭제하여 [b c] 를 렌더할 경우,
  • 문제: key값을 주지 않으면 a자리에 b를, b자리에 c를, c자리에는 아무것도 렌더하지 않는 번거로운 작업이 필요합니다.
    (key값을 주면 [a b c]에서 바로 a만 key값으로 잡아와서 빠르게 삭제할 수 있습니다.)
• 데이터 맵핑 측면
  • 예시: [a b c] 리스트에서 a앞에 z를 추가하여 [z a b c] 를 렌더할 경우,
  • 문제: key값을 주지 않으면 리액트는 index를 default key값으로 활용하는데 이는 a(기존 index 0)가 가지고 있던 데이터가 z(새로운 index 0)에 맵핑되어 버립니다.(참고한 글)

두 가지 측면을 모두 생각해보았을 때 고유한 key값을 가져야 한다는 의미는 배열 내 형제끼리 중복되지만 않으면 된다라는 것 뿐만 아니라, 리렌더 되었을 때도 자신만의 고유한 key를 유지할 있어야 한다는 의미로 이해했습니다. 🤔 제가 이해한 내용이 맞다면, index를 순차적으로 변환해서 'a', 'b', 'c', ...를 key값으로 주는 방식은 위의 데이터 맵핑이 꼬이는 문제를 전혀 해결할 수 없다고 생각됩니다. 따라서 리액트에서 필요로하는 key값을 주려면 nano id와 같은 id 생성기를 이용해야겠다고 생각했습니다.

그런데 같은 글에 따르면, 지금 제 경우처럼 리스트가 변하지 않고 정적일 것이 보장(재정렬, 필터되지 않음)되는 경우인데 딱히 쓸만한 id를 가진 것도 아닌 경우에는 굳이굳이 id를 생성하기 보다는 index를 key로 사용해도 좋다고 하고 있습니다...! 제가 생각해도 key가 꼭 필요한 상황이 아니어서 이런 경우에는 key값을 생략하려고 합니다..!

[zereight]

하루가 복지다

[Tanney-102]

여기 글을 참고하면 좋을 것 같아요!

[Tanney-102]

하루가 올린 블로그랑 같네요 ㅎㅎ

[wmakerjun]

우와 갓정리다!!!!

[wmakerjun]

하루는 역시 우테코 복지

[hchayan]

한줄정리 : 내부 요소 추가 삭제 작업시 문제 발생. 내부요소 정적(추가x,삭제x,필터링x,재정렬x)일때는 괜찮다.

[zereight]

대박 고맙습니다아아아

[seojihwan]

위치의 수정이 바뀌지 않는 상황을 인지하였을 때에는 index를 사용하는 것은 문제가 없으므로 안티패턴이 아니라고 생각합니다.