Q. Promise.all의 기능과 필요한 이유에 대해서 설명해주세요.
A. Promise.all은 여러 프로미스의 결과를 집계할 때 유용합니다.
Promise.all은 요소 전체가 프로미스인 배열을 받고 새로운 프로미스를 반환합니다.
복수의 URL에 동시에 요청을 보내고, 다운로드가 모두 완료된 후에 콘텐츠를 처리하고자 할때 유용하게 사용할 수 있습니다.
AA. Promise.all()은 여러 비동기 작업을 동시에 처리하고 순서를 유지하기 위해서 사용합니다. Promise를 요소들로 하는 배열은 전달인자로 받아 이후에 then으로 resolved된 비동기 작업을 처리할 수 있습니다.
공개 API를 쓰는 경우 필요한데, 공개 API에서 한번에 100개의 아이템만 조회할 수 있는 경우 일반적으로 Promise나 async/await을 사용하면 순차적으로 100개의 비동기 작업의 실행과 리턴을 기다려야만 합니다. 동기적인 코드 실행과 실행 시간에 별 차이가 없습니다. 하지만 Promise.all()을 쓰면 컴퓨터와 Node.js가 가능한 만큼 여러 쓰레드를 사용하여 작업할 수 있어서 코드 실행 시간을 단축할 수 있습니다.
Q. 순수 함수란 무엇인가요? 불변성과 사이트 이펙트와 연결하여 설명해주세요.
A. 순수 함수란 오직 함수의 입력만이 함수의 결과에 영향을 주는 함수를 의미합니다. 또한 순수함수는 네트워크 요청과 같은 side effect가 없고, 입력으로 전달된 값을 수정하지 않는 불변성을 가지고 있습니다.
순수함수의 특징으로는 어떠한 전달 인자가 주어질 경우, 항상 똑같은 값이 리턴됨을 보장합니다.
AA. 순수함수는 함수형 프로그래밍에서 자주 사용되는 개념으로, 오직 함수의 입력만이 함수의 결과에 영향을 주는 함수를 의미합니다. 또한 사이드 이펙트가 없어야 합니다. 사이드 이펙트는 쉽게 말해서 외부 변수를 참조하거나, 변경하는 모든 종류의 코드를 의미합니다. 즉, 순수함수는 함수 body내에 있는 코드만 점검하면 되기 때문에 간결하게 코드를 작성하고 사고하는데 도움이 됩니다.
자바스크립트에서 순수함수를 제작하기 위해서 데이터의 불변성을 유지하는 것이 중요합니다. 함수의 전달인자로 참조 자료형이 전달되는 경우, 해당 객체 자체를 바꿔서 사이드 이펙트를 만들 수 있고, 이는 해당 데이터의 불변성을 손상시킬 수 있습니다. 그래서 배열의 불변성을 보장하는 메서드인 map, filter, reduce 등이 각광을 받게 되었습니다.
Q. React의 state와 props에 대해서 설명해주세요
A. Rect state란 컴포넌트의 사용 중 컴포넌트 내부에서 변할 수 있는 값을 의미하고 props란 상위 컴포넌트로부터 전달 받은 값, 즉 외부로부터 전달받은 값을 의미합니다. React 컴포넌트는 props를 함수의 전달인자처럼 전달 받아 이를 기반으로 화면에 어떻게 표시되는지를 기술하는 React 엘리먼트를 반환합니다.
AA. React에서 state는 변할 수 있는 데이터를 의미합니다. 애플리케이션의 작동 구조를 봤을때, 변할 수 있는 값이면 React의 상태로 적절합니다. 예를 들어서, input의 value는 사용자가 값을 입력하면 변경될 수 있는 값이기 때문에 state로 적절합니다. 또한 Social media에서 게시글 역시 다른 유저가 추가로 게시글을 작성하고 난 뒤에는 게시글의 수가 변할 수 있기 때문에 게시글 배열로 state로 적절합니다.
다만, input의 value는 하나의 컴포넌트에만 영향을 주고 게시글의 배열은 여러 컴포넌트에 영향을 줄 수 있는 차이점이 있습니다. 다른 컴포넌트에 영향을 미치는 정도에 따라 전역 상태와 지역 상태로 구분할 수 있습니다.
props는 외부에서 전달받아 컴포넌트 내에서는 변할 수 없는 값입니다. 그래서 React에서는 props를 중간에 변경하는 것을 권장하지 않고, lifting state up(상태 끌어올리기)를 통해 상태를 변경시키고 변경된 상태값을 props로 내려주어 side effect를 최소화시킵니다.
Q. React 컴포넌트의 key 속성에 대해서 설명해주세요.
A. Key는 React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕습니다.
AA. key 속성은 같은 컴포넌트를 여럿 렌더링할 때, 다른 컴포넌트임을 구분하기 위해서 사용하는 속성입니다. 예를 들어, 100개의 게시글 중 하나의 게시글만 변경되었을 때, 해당 게시글만 새롭게 재렌더링하고, 다른 게시글은 그대로 둘 수 있습니다. 이렇게 key 속성을 활용하면 React가 DOM을 직접 제어하는 것보다 더 빠르게 렌더링을 할 수 있습니다.
Q. useEffect의 dependency array에 대해서 설명해주세요.
A. 먼저, useEffect란 컴포넌트 내에서 Side Effect를 실행할 수 있게 하는 Hook입니다.
useEffect는 첫 번째 인자로 콜백 함수를 받고 두 번째 인자로 배열을 받는데 이 배열을 dependency array라고 부릅니다.
dependency array, 즉 종속성 배열이라고 부르는 이유는
useEffect의 실행이 화면에 첫 렌더링 될때, 그리고 종속성 배열의 value값이 바뀔 때마다 실행되기 때문입니다.
만약 dependency array로 빈 배열이 전달된다면 실행은 첫 렌더링될 때만 실행됩니다.
AA. useEffect는 React Function Component에서 라이프사이클을 대신할 수 있는 React Hook입니다.
프론트엔드 개발에서는 불가피하게 side effect가 발생합니다. 대표적으로 ajax 요청, DOM reference 참조 및 변경 등이 있습니다. 이런 작업을 처리할 때는 React에서 제공하는 useEffect의 callback 함수 내에서 처리해야 합니다. 그렇지 않으면 리액트가 컴포넌트를 렌더링하기 전에 side effect가 생기면 해당 side effect가 화면에 바로 적용되지 않습니다.
useEffect에 dependency array를 주지 않으면, 상태가 변경될 때마나 컴포넌트가 리렌더링이 됩니다. 간단한 local state가 계속 변경될 때마다 새롭게 컴포넌트가 리렌더링 된다면, 이는 성능에 악영향을 미칩니다. 그래서 특정 상태나 props가 변경될 때만 작동하게 할 수 있도록 dependency array요소를 정하면, 해당 상태나 props가 변경될 때만 작동합니다. 반대로 컴포넌트 렌더링 시 딱 한번만 작동되게 하고 싶으면 dependency array에 아무것도 넣지 않으면 됩니다.
Q. CSR과 SSR의 차이점에 대해서 설명해주세요.
A. SSR과 CSR의 주요 차이점은 페이지가 렌더링되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다. CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침하지 않고, 동적으로 라우팅을 관리합니다. SSR은 경로가 변경될 때마다 새로운 정적파일을 요청합니다.
AA. CSR과 SSR은 각각 클라이언트 사이드 렌더링, 서버 사이드 렌더링의 약자입니다. 최초 웹이 탄생하고, ajax가 보편화되기 전까지는 서버에서 HTML파일을 전부 만들어서 브라우저에 전달하고, 브라우저에서 해당 HTML 파일을 화면에 보여주는 SSR 방식이 보편적이었습니다. 이후 ajax가 보편화되고 나서부터는 CSR이라는 개념이 대두되었습니다. CSR은 ajax 요청을 통해 페이지의 일부분에 필요한 정보만 받아서 브라우저에서 렌더링을 할 수 있는 장점이 있습니다. 즉, 단순한 웹 페이지가 아니라 유저와의 즉각적인 상호작용이 필요한 웹 애플리케이션에 적절합니다.
Q. GET 메서드와 POST 메서드의 차이점에 대해 설명해주세요.
A. GET 메서드는 존재하는 자원에 대한 요청을 위한 메서드이고 POST 메서드는 새로운 자원을 생성하기 위한 메서드입니다.
AA. GET 메서드는 서버의 리소스를 조회하고, POST 메서드는 서버의 리소스를 변경하는 HTTP 메서드입니다.
GET은 단순히 조회를 요청하기 때문에 body를 보내지 않는 것이 보편적이고 query parameter나 path parameter를 씁니다. POST는 리소스의 생성 및 변경을 의미하기 때문에, body에 원하는 변경 사항을 자세하게 적습니다.
GET 메서드는 요청을 무한대로 보내도 같은 요청을 회신받을 수 있는 멱등성을 가지고 있습니다. 반면 POST는 요청을 무한대로 보내면 최초 응답과는 다른 회신을 받게 됩니다. 이미 해당 리소스가 생성이 되어있거나, 변경되기 때문에 멱등성이 없습니다.
Q. HTTP 메시지에 대해 설명해주세요.
AA. HTTP 메시지는 크게 start-line, header와 body로 나뉩니다. start-line은 어떤 프로토콜을 사용하는지, 어떤 HTTP 메서드인지, 상태 코드는 무엇인지 등 해당 요청 / 응답의 핵심 정보가 담겨있습니다.
header는 요청/응답에서 공통으로 자주 다루는 정보들이 담겨있습니다. 예를 들면 body의 Content-type이 무엇인지, 캐시의 유효 기간은 얼마나 되는지 등 공통으로 자주 주고받는 정보가 담겨있습니다. body는 해당 요청/ 응답에서 꼭 다뤄야 하는 중요한 정보를 담고 있습니다. 보통 추가/변경/삭제하고 싶은 리소스의 자세한 정보를 담기도 하고, 응답의 경우 요청자가 꼭 알아야하는 리소스에 대한 정보를 담게 됩니다.
Q. SOP CORS에 대해서 설명해주세요.
AA. SOP는 Same Origin Policy의 줄임말로, 동일 출처 정책을 의미합니다. uri의 프로토콜, 호스트, 포트 이 3가지가 모두 동일해야 같은 출처(Same Origin)으로 인정하게 되는데요, 이 정책이 필요한 이유는 동일한 출처가 아닌 곳에서 요청이 오는 경우 해당 요청을 막아 높은 보안성을 유지하기 위함입니다. 대부분의 모던 브라우저에서는 이 정책을 기반으로 동일 출처로의 요청이 아니면 요청 자체를 막습니다. 크롬, Edge, Firefox와 같은 모던 웹 브라우저 사용을 권장하는 이유입니다.
다만, 서버에서 다른 출처에서의 요청을 허용하게 해줄 수 있는 CORS 설정을 해준 경우는 접근할 수 있습니다. 모든 출처로 부터의 요청을 허용할 수도 있고, 일부 출처로의 요청만 허용하는 것도 가능합니다. expressjs에서는 cors 미들웨어로 상황에 맞게 cors 설정을 제어할 수 있습니다.
