TIL_2023.06.07

이얏호·2023년 6월 7일
0
post-custom-banner

최근에 계속 진행중인 영화 사이트 제작이다.

그 중 수정, 삭제 기능의 기본 베이스를 구축하는 과정이었는데
내가 생각한 방식과 팀원이 생각한 방식에 약간의 차이가 존재했다.

우선 나는 localstorage에 저장되는 정보 자체에 0부터 시작해서 1씩 더해가며 일종의 순서를 따로 부여해주었다. 만약 중간 번호가 삭제되더라도 돌아가거나 채워넣지 않고 계속해서 1씩 더해지며 등록된 순서를 나타내는 번호이다.

그 번호를 사용해서 내가 수정하거나 삭제하고 싶은 댓글 자체를 특정해내는 과정을 사용했다.

let reviewListNum = target.parentNode.parentNode.children[2].id;
    review.forEach((e) => {
      if (e[3] == reviewListNum) {
         ~~실행
      }
    });

이벤트 버블링을 사용해보려다가.. 조금 지저분해지긴 했으나.. 로직은 다음과 같다.
위에서 언급한 번호를 해당 태그의 id값으로 넣어두고 불러온 데이터의 번호값과
id의 번호값을 비교해서 내부를 실행하는 구조이다.


반면 팀원이 구현한 방식은 조금 달랐다.
html을 생성하는 과정에서 for문 안에서 index를 함수에 전달하여 localstorage에 저장된 인덱스 번호와 같은걸 바로 수정, 삭제해주는 방식이었다.

comments.forEach((comment, index) => {
    ~ 생략
    const deleteButton = document.createElement("button");
    deleteButton.innerText = "삭제";
    deleteButton.addEventListener("click", () => deleteComment(index));
    ~ 생략
  });

이것처럼 버튼을 생성할때 addEventListener를 이용해서 함수 실행 시 부여받았던 인덱스번호를 바로 날려주는 형태였다.

내가 사용했던 방식은 따로 데이터를 추가 저장해야할 필요도 있었고
대조하는 과정도 거쳐야해서 코드가 길어졌다.

반면 팀원이 사용한 방식은 따로 데이터를 추가 저장할 필요도 없었고
대조하는 과정 역시 생략되었다.

그래서 이 방식이 더 괜찮아보였는데 문제가 살짝 있었다.
그 문제 역시 해결이 불가능 한 것은 아니었지만 댓글을 등록순, 최신순으로 정렬하는 기능을 추가하는 과정에서 문제가 발생했다.


등록순 / 최신순 버튼을 만들어서 버튼을 누를 때마다 댓글의 정렬 방식을 바꾸어주는 작업이었는데,
버튼을 누를 때 각각 sortOnOff라는 변수에 0 혹은 1을 넣어주었고

let review = JSON.parse(localStorage.getItem(id));

if (sortOnOff == 1) {
    review.reverse();
  }

이런식으로 sortOnOff변수의 값에 따라 댓글을 불러올 때, 저장 정보 순서를 reverse()함수를 통해서 바꿔 주었다.


팀원이 사용했던 저장, 정보 비교 방식에서 해당 방식으로 구현을 해보았는데 일반적인 상황에서는 잘 작동하였다. 등록순도 최신순도 이상없이 정렬이 바뀌어서 그대로 진행하려 했으나, 문제는 최신순(역순)으로 정렬구조를 바꾼 상황에서 수정 혹은 삭제를 할 경우 였다.

지금 구조를 보면 localstorage에서 값을 가져와서 JSON parse를 통해 배열, 객체 형식으로 변환한 것을 변수에 담고 해당 변수를 reverse해주는 방식인데
그렇게 반전 된 상태에서 삭제버튼을 누를 경우 localstorage의 저장된 인덱스 넘버는 그대로기에 그 차이로 인해서 다른 댓글이 수정되거나 삭제되는 경우가 발생했다.

반면 내가 취했던 저장 방식에서는 인덱스 번호로 판별하는 것이 아니라 별개의 인식 번호로 판별했기에 정보가 반전 된 상태에서 수정, 삭제기능을 사용해도 정상적으로 원하는 정보가 수정되었다.


정상적으로 작동을 하고, 코드 자체도 깔끔하지만 타 기능이 추가되면서 해당 코드가 문제가 생기는 걸 처음 겪었다.

정렬 기능을 추가하지 않은 시점에서는 팀원분이 짠 코드가 더 간략하고 보기 좋았지만
정렬 기능을 추가하게 되면서 두 기능간에 문제가 발생했다.

현 시점에서 가장 최선의 상황을 만들고자 하는게 중요하지만,
앞으로 추가 될 기능이나, 변경사항 등이 예견된다면 그 부분에 대해서도 예외처리나,
문제가 발생하지 않는 방향으로 만드는 것이 중요한 것 같다.

특히나 팀 작업을 할 때는 정보가 저장되는 모습을 어떻게 저장해서 어떻게 가공할지 미리 청사진을 그려놓고
작업을 시작하는 것이 도움이 되는 것 같다.

작업을 나누어서 진행했는데, 저장 될 정보의 모습을 알지 못한 채로 작업을 진행하니 특정 부분들에 대해서 가정을 해가면서 작업을 하고 그 후에 정보를 공유하면서 수정하게되니 그 과정이 더 길어진 것 같다.

(배열로 할지.. 객체로 할지.. 저장할 정보는 무엇을 넣을지.. 추가로 무엇을 저장해야하는지.. 이러한 정보를 어떠한 모습으로 가공해서 어떤 기능에 사용을 할건지.. 등등)

profile
열심히 신나게 화이팅!
post-custom-banner

0개의 댓글