이전까지 배운 키/값 쌍을 이용하는 방법들로도 충분히 많은 쿼리를 할 수 있지만 완벽한 것은 아니다. 이 때 $where 절은 자바스크립트 코드를 그대로 받아서 실행할 수 있다. JS코드를 그대로 갖다 쓰므로 거의 모든 쿼리를 표현할 수 있다. 다만 DB에 자바스크립트 코드를 그대로 돌린다는 발상 자체는 보안적으로 매우 좋지 않다. 따라서 최대한 자제하는게 좋으며, 사용자(혹은 해커가) $where절이 포함된 구문에 임의의 자바스크립트 코드를 전달하지 못하게 보안 장치를 철저히 마련해둬야 한다. 그 외에도 - 일반 쿼리 대비 속도가 훠어어얼씬 느리다 - $where 절에는 인덱스를 사용할 수 없다 - 일정부분은 대체용으로 $expr 연산자도 있다 보안에 자신 없으면 쓰지말자. 일반 쿼리와 인덱스를 최대한..

string 타입은 범위가 매우매우 넓다. 막말로 'x'같은 리터럴 뿐만 아니라 120만자 짜리 소설도 string타입에 포함된다. 어떤 면에선 any와 비슷한 문제를 안고 있다고 해도 과언이 아닌 정도이다. 따라서 string 타입 변수를 선언하고자 한다면. 그보다 더 좁은 타입이 적절하지는 않을지 검토해봐야 한다. 1. string 남발 string이 남발되면 코드 작성자의 의도대로 돌아가지 않을 뿐만 아니라, 타입 체커조차 이를 파악할 수 없게된다. // 최초 설계 의도는 // 출시일은 'YYYY-MM-DD'로 출력하고 // 음원은 'studio' or 'live'로 분류하고자 한다 interface Album { artist :string; title :string; release :string;..

유니온 타입의 속성을 여럿 가지는 인터페이스를 작성 중이라면 아래와 같은 이유로 다시 한번쯤 생각해봐야 한다. - 유니온의 인터페이스는 속성 간의 관계가 불분명할 수 있다 - 인터페이스의 유니온이 보다 더 정확하고 TS가이해하기도 좋은 형태이다 1. 유니온의 인터페이스(bad) 아래 예시 코드를 보자. 점/선/면을 그리는 인터페이스를 만드려고 하는데 뭔가 이상해보인다. 레이아웃은 LineLayout인데 페인트는 FillPaint면 이상한거 아냐? interface Layer { layout :FillLayout | LineLayout | PointLayout; paint :FillPaint | LinePaint | PointPaint; } 2. 인터페이스의 유니온(good) 위 예시를 태그된 유니온을 끼..

처음 타입스크립트를 경험하면 strictNullChecks 설정때문에 null, undefined값 오류가 난무하는 모습을 보게될 것이다. 또한, 오류를 걸러내기 위해 if 문을 코드 전체에 추가해야되나 고민이 될 것이다. 사실 이 고민은 한 값의 null 여부가 다른 null 여부에 암시적으로 관련되도록 설계하지 않으면 해결할 수 있는 문제이다. 쉽게 말해 null인 값과 아닌 값이 혼용되는 상태를 만들지 말아야 한다는 뜻. 1. null 값의 암시적 연관 왜 if문을 계속해서 써야된다는 생각이 들었을까? 그 과정을 나열해보면 아래와 같을 수 있다. 함수 A 내부에선 a, b, c의 지역 변수를 쓰고 있다 ☞ 이들은 각자가 null | undefined 일 수 있다 A를 갖다쓰는 B는 b, c의 값이 ..

1. 주석에 관하여 가끔씩 코드를 짜다보면 구구절절 주석을 달아주고 싶은 충동이 들 때가 있다. 주석을 달아주는 것 자체가 나쁘다는 뜻은 아니지만, 사람이 일일이 작성하는 일이다보니 이따금 아래와 같은 문제가 발생할 수 있다 코드와 맞지 않는 내용의 주석 코드를 새로 갱신했지만 주석 작성을 깜빡하는 경우(동기화 실패) 장황한 주석 가. 예시 아래 예시를 보자. 어떤 생각이 드는가? 일단 정의한 함수보다 더 길고 장황한 주석이 눈에 띤다. 또한, 색상을 반환하다면서 결과물은 rgb 값이 담긴 객체이다. 아마 코드 작성자가 코드 짜다가 까먹었나본데 여하튼 보기 좋은 상황은 아니다. /** * 페이지 색상을 반환합니다 * 0 or 1개의 매개변수를 받습니다 * 매개변수가 없을 시 표준 색상을 반환합니다 * 매..

효과적 타입 설계를 위해선 유효한 상태만 표현할 수 있는 타입을 만들어 내는 것이 가장 중요하다. 즉, 타입 설계시 어떤 값들을 포함하고 어떤 값들을 제외할지 신중해야 한다는 뜻이다. 물론 유효한 상태만 표현하기 위해 코드가 길어지거나 표현이 어려워질 수도 있다. 그러나 결국엔 시간을 절약하고 고통을 줄이는 방향이 될 것이다. 1. 유효한 상태 명확히 정의내리기 어렵지만 어떤 속성들에 대하여 정보가 부족하거나 충돌하지 않는 상태라고 생각할 수 있다. 아래 예시를 통해 유효하지 않은 상태를 보자. 가. 렌더링 상황(예시) 분기 조건이 명확히 분리되어 있지 않다 isLoading이 true인데 동시에 error가 존재하면? 로딩중인거여 에러가 났다는거여? 현 상태는 두 가지 속성이 충돌할 수 있음을 내포한다..