코딩애벌레

Typescript는 굉장히 까다로운 친구로, Props로 데이터를 전달 받았다면 해당하는 데이터의 타입을 정의해주어야 사용가능하다. 이때 총 3가지 방법이 있는데, 동일하게 Generic(제너릭)을 사용한다. interface / type / 직접정의 하는 방법이다. 빠르게 살펴보도록하자. /////////////// App.tsx ///////////////import React from "react";import TodoList from "./components/TodoList";const App: React.FC = () => { // ts 구간 const todos = [{ id: "1", text: "Finish the course" }]; return ( // html 구간 ..

문제는 앞서 말했던 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를 진작 사용하지 않았는가? 기능 구현이 우선이다고 생각하고 신경쓰지 않았던 부분이다. 처음에는 오히려 편..

이제 서론은 거의 쓰지 않을 것 같다. (바쁘자나~)computed(): 계산된 속성을 정의하는 함수: 미리 계산된 속성을 사용하여 템플릿에서 표현식을 단순하게 하고 불필요한 반복 연산을 줄인다: 읽기 속성(computed로 정의된 변수는 외부에서 변경 불가)을 띈다 위처럼 출력하기 위해 html에서 직접 삼항 연산자를 사용하는 방법도 물론 문제가 되지 않지만, 최대한 가시성 좋게 하기위해서는 연산은 따로 진행하고 출력만 할 수 있게 하는 것이 좋을 것이다. 또, 여러번 연산해야한다면 html 요소가 계속 길어지며 보기 좋지 않다. 이를 위한 방법이 두가지가 있다.지금까지 해왔던 함수 정의를 통해 변수를 직접 전달해주는 방법은 모두 알 것이다. 하지만 computed를 이용한다면 더 효율적이고 직관적인 ..

이젠 서론 쓸 시간도 없다! 바로 본론!v-if: 조건부 렌더링을 수행하는 directive : 표현식 값의 true/false를 기반으로 요소를 렌더링: django html에서 클라이언트의 상태와 요청에 의한 출력 화면과 유사 위처럼 정의했을 때, 클릭할 때마다 isSeen은 !isSeen에 의해 true는 false로, false는 true로 바뀌는 반응형 변수를 활용할 수 있으며, p tag 내부에 v-if와 v-else의 조건에 의해 html에 보이는 화면이 바뀐다. if와 else가 있다면 짝궁인 else-if도 있다. 반응형 변수에 random함수를 입혀준다면 호출 시, 랜덤하게 출력되는 모습도 확인할 수 있다.그렇다면 모든 tag에 v-if를 입혀주어야 할까? 물론 아니다. 전체를 감싸고있..

저번엔 Attribute 속성을 추가하는 것을 배웠다. 동일하게 Class와 Style 속성을 Binding 하는 것을 배울 것인데, 속성으로 다루지 않고 나눈 이유는 반응성 Web에서 가장 많이 다루는 속성이기 때문이다. 예를들어, 클릭했을때 새로운 Attr가 생기는 것 보다는 bootstrap의 class 추가 혹은 style의 추가로 반응을 띌 수 있다. front에서 중요한 부분이니 집중해보자!v-bindClass and Style Bindings: class와 style은 모두 HTML 속성이므로 다른 속성과 마찬가지로 v-bind를 사용하여 동적으로 문자열 값을 할당할 수 있다: Vue에서 class 및 style 속성 값을 v-bind로 이용할때 객체 or 배열을 활용하여 on / off 혹..

오늘은 간단하게 Directive의 기본 형태와 어떤 종류가 있는지에 대해 살펴볼 예정이다. 굳이 나눈 이유는... 그만큼 세부사항이 중요하기 때문에 나눠 다루려고 한다. 가보자고Template Syntax: DOM을 기본 구성 요소 인스턴스의 데이터에 선언적으로 바인딩(연결) 할 수 있는 HTML 기반 템플릿 구문을 사용 Text Interpolation: 데이터 바인딩의 가장 기본적인 형태 ( Mustache syntax : 콧수염 구문 ): 다른 언어에서도 많이 사용하는 형태로, 해당 구성 요소 인스턴스의 속성 값으로 대체한다Raw HTML: 변수나 함수를 호출하는 것이 아니라 HTML 자체를 호출 할 수 있는 방법: 콧수염 구문은 데이터를 일반 텍스트로 해석하기 때문에 v-html을 이용하여 ht..