면접관님께 컨텍스트와 리덕스의 차이에 대한 질문을 받았는데요. 프론트엔드 개발자라면 당연히 자신있게 말씀드려야 하는 부분임에도 불구하고, 어중간하게 알고 있는 점 + 긴장한 탓으로 횡설수설하게 되었습니다. 같은 실수를 반복하지 않도록 컨텍스트와 리덕스의 차이에 대해 추가적인 공부를 했고, 그것에 대한 고찰을 게시글로 남깁니다. (좋은 질문을 주신 면접관님께 너무 감사드립니다!) 리렌더링 리액트는 기본적으로 state가 변경되면 리렌더링이 일어납니다. 리렌더링이 일어나면 내부에 있는 중첩된 컴포넌트들도 재호출 될 것입니다. 따라서 상위 컴포넌트의 state가 변경되면 하위 컴포넌트들의 연쇄적인 리렌더링이 야기됩니다. 컨텍스트(Context) 컨텍스트의 사용 용도는 별도의 문맥(Context)을 만들어 그 ..
함수 표현식과 타입 할당 자바스크립트에서 함수는 표현식으로 나타낼 수 있다. 함수 타입을 만들고, 함수 표현식에 타입을 할당하면 함수에 타입을 깔끔하게 명시할 수 있다. type DiceRollFn = (sides:number) => number const rollDice: DiceRollFn = (sides) => { return sides } const rollDiceAndPlusOne: DiceRollFn = (sides) => { return sides + 1 } 다른 함수의 타입 참조 : typeof fn 다른 함수의 타입을 그대로 참조하기 위해 typeof fn를 사용할 수 있다. 타입에서의 typeof는 별도의 값을 산출하는 연산자가 아님을 기억하자. declare function fetch..
DELETE, UPDATE를 할 때 id를 참조하여 바꾸지 않으면 1175 에러가 난다. Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column. To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect. 언제나 키 컬럼을 참조해서 row를 변경, 삭제할 수 있다면 좋을 것이지만, 간단한 테스트나 연습의 경우에는 그러기가 좀 곤란하다 그럴때는 safe mode를 해제해주면 된다. set sql_safe_updates=0;
다이어그램 회원가입시 customers 페이지에 개인정보가 저장된다. (id가 고유하게 존재한다.) orders는 회원이 물건을 구매할 시 row가 생성되는 테이블이다. (id가 고유하게 존재한다.) orders의 개별 id는 고유하지만, 회원 정보가 있어야만 물건을 구매할 수 있으므로, orders의 customer_id는 customers의 id를 외래키로 참조한다. 하나의 회원이 여러개의 orders row를 가질 수 있으므로, 이는 일대 다 관계에 해당한다. SQL문 // customers 테이블 생성 CREATE TABLE customers ( id INT AUTO_INCREMENT, first_name VARCHAR(50) NOT NULL, last_name VARCHAR(50) NOT NUL..
문제 DELETE나 UPDATE 사용할 때, 메인 쿼리에서 만들어낸 서브쿼리를 직접적으로 참조하면 에러가 발생한다. DELETE FROM people WHERE name = (SELECT name FROM people WHERE name = 'PJY' LIMIT 1); 위의 SQL에서 에러가 발생했다. 해결 1. DELETE나 UPDATE 사용 시 서브쿼리를 사용하지 않는 방법 DELETE FROM people WHERE name = 'PJY' LIMIT 1; 서브쿼리를 사용하지 않는 편이 성능상으로나 쿼리 가독성으로나 더 좋은 방법이다. (+ LIMIT 거는 이유) 한번에 너무 많은 ROW를 삭제하면 데이터베이스에 부하가 가해지므로, 다른 트랜잭션이 처리되지 않아 데드락이 걸릴 수 있다. 이를 방지하기..
타입 단언, 타입 선언 interface Person {name: string}; const alice: Person = { name: 'Alice' } // Person 타입 (타입 선언) const alice = { name : 'Alice' } as Person // Person 타입 (타입 단언) 두 가지 방법은 결과가 같아보이지만 그렇지 않다. 첫 번째 방법은 변수에 타입을 붙여 타입을 선언한 것이고, 두번째는 as Person으로써 타입을 단언한 것이다. 타입 선언은 타입 체커가 동작한다. const alice: Person = {}; // -- 타입 에러 const bob = {} as Person; // 오류 없음 타입 선언은 할당되는 값이 해당 인터페이스를 만족하는지 검사한다. 앞의 예제..
클린코드 개인 프로젝트의 헤더 컴포넌트 코드를 정리해보겠습니다. 내 코드를 타인이 봤을 때 이해할 수 있을까? 라는 목표로 코드 정리를 진행해보았습니다. Before 선언형과 명령형이 뒤섞여있습니다. 동료들이 이 코드를 보고 한번에 이해하기는 어려울 것 같습니다. After 최대한 선언적으로 고쳐보고자 노력했습니다. Header 컴포넌트이므로 header 태그와 header_content는 유지한 상태에서 내부 코드를 최대한 추상화 해보았습니다. 커스텀 링크나 커스텀 버튼의 경우, props나 핸들러를 통해 어떤 역할을 할 지 명시해주었습니다. 결론 생각보다 재밌는 작업이지만, 시간이 많이 걸리는 것 같습니다. 하지만 좋은 동료가 되려면 의도적인 연습은 필수일 것 같습니다. 아직 모자란 직관과 실력이지만..
클린코드를 시청한 이유 지금까지는 언어의 이해와 구현에 많은 리소스를 투자해왔습니다. 구현에 급급하다보니 질 좋은 코드가 나오기 힘들었습니다. 앞으로는 협업을 위한 스킬에 많은 리소스를 투자하려 합니다. 그 첫걸음은 클린코드라고 생각해서 클린코드 영상을 시청하게 되었습니다. https://www.youtube.com/watch?v=edWbHp_k_9Y 클린코드의 목적 단일 목적을 하는 코드가 흩뿌려져 있거나, 하나의 함수가 여러 역할을 하고 있다면 동료 개발자들이 제 코드를 읽기 어려워 할 수 있습니다. 또는 나만 알고 있어서 나만 수정할 수 있는 코드가 생길 수도 있습니다. 이는 조직적 관점에서 좋은 현상이 아닙니다. 코드의 질에 따라 생산성에 차이가 생기며, 생산성은 시간이고 시간은 곧 돈이기 때문입..
Intersection Observer API을 도입하려 했던 이유 프로젝트중 특정 요소가 보인 뒤에 다음 요소가 화면에 렌더링 되게끔 구성을 하고 싶었습니다. 이를 구현하기 위해서 여러 방법이 있겠지만 Intersection Observer API가 가장 좋은 방법이지 않을까 해서 위의 API를 사용해 보았습니다. 코드하기에 앞서, 공식문서에서 Intersection Observer API의 스펙을 살펴보았습니다. 간추린 공식문서 설명 intersection observer API는 부모 엘리먼트나 탑 레벨 문서(document)의 뷰포트를 이용하여 타겟팅한 엘리먼트의 변화를 감지하는 API 입니다. 즉, 타겟팅 엘리먼트의 감지 여부에 조건을 걸어 어떤 역할을 부여할 수 있다는 의미입니다. Inters..
세션, 표현, 응용 계층 전송 계층을 통해 데이터를 받게되면 세션, 표현, 응용계층에서 올바른 데이터를 프로세스와 연결지어 사용합니다. 세션 계층은 인증과 허가 등 보안에 관련된 영역을 담당하고, 표현 계층은 인코딩 등 확장자에 관한 개념을 담당하며, 응용 계층은 프로세스가 데이터를 사용하는 영역으로써 사용자 인터페이스에 보여지는 공간이라고도 볼 수 있습니다. 하지만 위 세 계층은 프로그래밍에 따라 역할이 다소 달라질 수 있으며, 상당히 추상적인 개념입니다. 따라서 요즘에는 OSI 계층을 일부 통합한 TCP/IP 계층으로 많이 표시합니다. 그림 요약 응용 계층에 속하는 HTTP 프로토콜은 위 그림과 같은 과정을 통해 다른 컴퓨터와 통신한다. 물리 계층에서는 정보가 담긴 전기 신호를 디지털 신호로 전환한다..
