분류 전체보기 (40) 썸네일형 리스트형 Request body validation middleware 회사에서 FrontEnd 뿐만 아니라 BackEnd 작업도 많이 한다, 지금도 Node.js기반 백엔드 작업을 굉장히 많이 하고 있는데 하면서 느낀점 및 꿀팁들을 작성해 보고자 한다. 언어가 JavaScript인 만큼 넘어온 요청 Body값이 Number인지 String인지 구분도 못하고 그냥 넘겨주는 것이 너무 불편하고 보기 껄끄러워서 Midleware를 활용하여 Request body 검증 로직을 수행하도록 했다. 그냥 Type검사 안하고 바로 통과해 버리는 JavaScript 보면 매우 불편해서 참을 수가 없다. 이게 회사 뿐만이 아니라 현재 진행하고 있는 Side project에도 적용을 해봤는데 매우 좋은 것 같다. 회사 로직을 옮겨 적을 수 없으니 Side project에서 진행한 Middle.. if를 통한 명확하고 확실한 조건 처리 if JavaScript뿐만 아니라 기타 다른 프로그래밍 언어에는 if문이 존재한다. 라이브러리, 프로젝트 기타 등등 if문 없이 프로그래밍이 가능할까? 라는 생각이 드는데,,, if문을 간단 명료하게 작성하기란 쉽지 않은 것 같다. 간단 명료한 if 작성 프로그래밍을 배우면서 귀에 딱지가 앉도록 클린코드에 대해 들어왔을 테지만 실제로 클린하게 코드를 작성하기란 여간 쉬운 일이 아니다. 이러한 일의 원인은 매우 다채로울 것이지만 그 중 하나가 바로 if문을 통한 예외처리 때문이리라,,, 어떻게 조건을 처리하는 것이 좋을까 이러한 조건 처리가 왜 프로젝트의 규모와 상관이 있을까? 대부분의 서비스는 수명이 길지 않은데 수명을 연장시키기 위해서는 누구나 알아보기 쉬운 코드로 작성되어야 한다. 따라서 복잡하고 .. Object, Array each 함수 Object? Array? forEach는 Array만 돌릴 수 있기 때문에 반복문을 돌릴려면 Object.keys(obj).forEach 뭐 이런 식으로 돌려야 하기 때문에 체이닝이 매우 많아진다. 그래서 Array이든 Object든 forEach를 돌릴 수 있게 구현해봤다. function each( target: Array | Type.HashType, cb: (item: T, key: string | number) => any ): void { if (!isFunction(cb)) return; match(target) .on( () => isArray(target) === true, () => { const arr: Array = target as Array; arr.forEach((item: .. TypeScript 타입 단언 Type assertion 타입스크립트는 명확한 타입 표기 및 타입 추론을 통해 타입을 판단한다. 하지만 때에 따라서 명확한 타입 표기가 불가능하거나 개발자가 임의의 타입을 값에 할당하고 싶은 경우도 존재한다. 이러한 경우 Type assertion을 활용하여 타입을 단언한다. interface Something { do: number | string; } 위 코드의 경우 do는 number 혹은 string의 타입을 가질 수 있다. 경우에 따라서 do 라는 값을 사용할 때 as를 활용하여 타입을 단언할 수 있다. /** * Add month function * @param {Date} target * @param {number} value * @returns {Date | null} */ export .. TypeScript 타입 추론 Type Inference TypeScript는 명시적인 타입의 표기가 없는 경우 타입의 정보를 제공하기 위해 사용. 즉 TypeScript가 코드를 해석해 나가는 동작 // num: number const num = 3 // isTrue: boolean const isTrue = true 타입을 여러 개 사용하는 경우 가장 근접한 타입을 Best Common Type이라고 함 // number | null const arr = [123, 4, null] Type Assertion Type Assertion은 타입을 단언하는 것을 의미. function getString(): any { return "123"; } const a = getString(); console.log((a as string).l.. Hook 규칙 Hook 규칙 Hook 은 JavaScript 함수이다. 하지만 Hook을 사용할 때는 두 가지 규칙이 있다. React의 함수 내에서만 사용되어야 한다. 즉 일반적인 JavaScript 내에서는 호출하면 안된다. React 함수의 최상단에서 호출해야 한다. useState 혹은 useEffect 의 경우 React가 순서를 지정해 놓기 때문에 rendering이 발생하는 경우 React가 지정한 순서에 따라서 hook을 호출할 수 있다. 하지만 if, for 안에서 hook을 사용할 경우 순서가 엇갈림에 따라 버그를 초래할 가능성이 있기 때문에 항상 React 함수의 최상단에서 hook을 호출하도록 규칙을 정해 놓은 것이다. 이러한 규칙은 linter plugin 참고. React 함수 내에서 Hook.. Code splitting Code splitting CRA로 만든 React App은 Webpack이 함께 설치된다. 따라서 번들링 시 Webpack에 의해 자동으로 번들링이 된다. App의 크기가 증가되면 자연스레 번들의 크기도 커지게 된다. 즉 App이 Load 되는 시간 역시 비례하여 증가하게 된다. 이러한 단점들을 보완하기 위해 코드 분할 을 활용하여 App의 성능을 개선하고 사용자에게 좋은 UX를 경험하게 한다. import 가장 단순한 방법으로 Dynamic import() 을 활용한다. // 기존의 import와 살짝 다른 모습 const AppTest = React.lazy(() => import("./AppTest")); Webpack이 위의 구문을 만난다면 Webpack이 자동으로 App의 코드를 분할한다. 즉.. 그놈의 TypeScript TypeScript, TypeScript, TypeScript ... 다들 좋다고 하길래 한 번 써봤다. 그리고 공부도 했다. 근데 솔직히 뭐가 좋은지 잘 모르겠다. 이 TypeScript는 React와 함께 사용하면 더 골때린다. 그냥 TypeScript를 JavaScript처럼 쓰는 것은 어떻게든 하겠는데, React랑 같이 사용하게 되면 처음보는 괴상한 타입들이 존재한다. 이런 부분만 제외하면 솔직히 매력있다. Java 공부하던 때도 생각나고 뭔가 안정적인 느낌도 들고,,, ( 무엇보다 파일이 파랑색이라 이쁨 ) 솔직히 그냥 any로 타협하고 싶은 마음도 많이 생긴다. 특히 이벤트 객체 타입을 지정할 땐 종료하고 노트북 닫고 싶은 마음도 많이 생겼다. 새로운 프로젝트를 시작했는데, React + T.. 이전 1 2 3 4 5 다음