코딩애벌레

문제는 앞서 말했던 Profile 페이지에서 carousel에 대한 삭제 이벤트가 진행 될 때, 마지막 carousel 요소가 삭제될 때 자동으로 바뀌어야하는데, 흰 화면이 나타나는 문제다.  증상을 살펴보면 중간에 있는 요소를 삭제 했을 때는 문제 없지만, 마지막 요소를 삭제했을 때는 다른 카드 페이지로 넘어가지 않는다. 반응성이 깨진건가 싶어서 Front와 Back을 나누어서 진행해봤다. 내가 만든 페이지에서는 로딩이 걸리지만, 실제로 웹을 구성할 때, pinia를 이용하여 Local 스토리지를 이용한다면 가장 빠른 반응을 보여 줄 수 있다. 내가 만든 페이지는 Back으로 요청을 보내고, 다시 데이터를 axios를 통해 호출한 다음 흩뿌려주기 때문에 1초 이상 걸리는 경우다.  당연히 web에 적용..

현재 UserProfileView.vue의 코드 길이는 무려 770lines에 달한다. 구성요소를 모두 한 페이지에서 전개했기 때문인데, 아래 Profile Page를 보면 구성요소가 무려 5가지가 있다.1. 프로필 정보2. Edit 버튼 및 dialog를 통한 정보 수정3. 사용자 금융 정보4. 꿀통에 담은 예금5. 꿀통에 담은 적금 근데 만들어진 페이지를 Refactoring 하니 불편한점이 조금 있더라. 예를들어 vue 에서 direct로 axios 요청을 보내는 경우가 많은데(1회용) 직접 분류해주어야한다. 물론 처음부터 코드를 나눠서 잘 짰으면 이런 일이 없을 것이고 유지보수도 더 편했을 것이다.. 먼저 carousel을 통해 접근 가능한 Detail 페이지를 재활용 해주어야 하는데, 실제 팝업..

사실 이틀이면 끝날 줄 알았다.. 누군들 알았겠는가 프로젝트의 코드가 잘못된 것이 많았다는 것을! 그래도 이렇게 리뷰하면서 고칠 수 있는 것도 행운인 것 같다. 다른 사람이 참고할 때 '얘네 야매네?' 라고 생각되는 것보다 훨씬 기분 좋다. 저번 시간에 발생된 버그 및 오류는 총 두가지며, 마무리 한다음 Detail Page Refactoring을 끝내려 한다. (물론 다른거 할거 많음!) 앞서 Detail 페이지에 대한 Refactoring은 List에서 불러오는 Detail (335 lines => 125 lines)Map에서 불러오는 Detail (284 lines => 136 lines)Recommend에서 불러오는 Detail (559 lines => 224 lines)Profile Page는 ..

이번엔 Saving(적금)을 해보자. Deposit(예금)과 동일하다고 생각할 수 있으나, 디테일 페이지에서 자유적립식과 정액적립식을 구분해놨기 때문에, 예금처럼 상품명 만으로는 해당 상품을 찾기 어렵다. 필요다면 Option의 데이터 정보에 자유적립인지 정액적립인지 구분하여 조건문을 통해 filter하거나 새로운 배열을 할당하면 된다. 하지만 도표는 양쪽 다 출력할 예정이기 때문에 결국 Detail을 dialog할 때는 같은 정보를 보여줄 예정이다. 즉! 적금과 똑같이 사용할 것이다. (실제 Detail 데이터는 도표기준으로 구분하지 않았다, List만 구분됨) 그리고 추가로 어제는 예상치 못했는데, dialog는 view(최상위 컴포넌트)에 변수가 존재하는데, 하위 컴포넌트에 OK 버튼이 존재하는 문..

배워야할 부분이 많지만, 진행했던 프로젝트에 대해 부족한 부분을 채우고 필요없는 부분을 다듬으면서 Code Refactoring을 해볼 예정이다. 1. Refactoring2. Component의 분리 (현재 View 14개, Component 7개)3. 무분별한 store 사용4. 중복 코드 및 미사용 코드 정리5. Profile 페이지에서 Detail 확인 시 스크롤 자동 하단 고정6. Profile 페이지에서 꿀통에 담은 상품 제거 시 버그 발생 디버깅하면서 느낀 것인데, pinia의 persist를 제거하고 하는 것이 오류가 덜 나는 것 같더라. 물론 로딩은 걸리지만 ㅎㅎ 왜 Component를 진작 사용하지 않았는가? 기능 구현이 우선이다고 생각하고 신경쓰지 않았던 부분이다. 처음에는 오히려 편..