제가한 답변은 아니지만 다른분들이 한 베스트 답변들을 모아봤습니다
면접보러 가기전에 3~4줄로 요약해보고 면접보러 가야겠네요
1.상태관리를 왜 할까요? 그리고 평소 state 관리는 어떻게 하시나요?
먼저 상태관리를 해야하는 이유는 리액트는 SPA으로 JS로 DOM을 조작하는 방식이 아니라 가상 DOM 방식을 사용해 화면에 있는 요소들을 제어합니다. 그렇기 때문에 직접 변수를 변경하는 것이 아닌 state를 통해 데이터를 관리해야 변경된 사항을 적용할 수 있습니다. - 상태관리를 사용하는 이점으로는 먼저 말했듯 변경사항을 적용할 수 있다는 점, 두번째로는 하나의 state의 값으로 하위 컴포넌트에 props로 전달하여 일관된 데이터를 공유할 수 있다는 점입니다. - state 관리는 크게 지역적, 전역적으로 합니다.
1. 먼저 해당 컴포넌트에서만 사용되는 state라면 컴포넌트 내에서 선언하여 관리합니다.
2. 만약 input의 값을 지정하는 state처럼 다른 컴포넌트에서도 지역적으로 쓰일 수 있는 state일 경우 커스텀 훅 내에서 state를 선언하여 사용합니다.
3. 어플리케이션 전체에서 사용될 수 있는 state라면 전역상태 관리 라이브러리인 redux나 zustand를 통해 store를 생성하여 전역적으로 관리합니다.
4. 추가적으로 tanstack-query를 통해 서버에서 데이터를 받았을 때는 queryKey를 통해 데이터 관리를 합니다.
2.Redux가 무엇인가요, 왜 Redux를 사용하시나요?
리덕스의 개념과 사용이유 리덕스는 state(동적데이터)를 모든 컴포넌트에서 접근 할 수 있도록 관리하는 하나의 관리소 입니다. 리액트의 특징인 단방향 데이터 (top-down)에는 , 데이터가 한방향으로 흘러 데이터의 이동이 부모-자식 컴포넌트 사이에서 자유롭지 못하다는 단점이 있는데요, 이를 해결하기 위해 나온 라이브러리 입니다. 이를 통해 어떤 컴포넌트에서든 해당 데이터를 핸들링(handling) 할 수 있어, 데이터 흐름이 유동적으로 변하여 , 보다 더 이용자에게 다양한 데이터를 제공해 줄 수 있습니다.
3.Redux 말고 다른 전역 상태관리 아는 것 하나와 차이점을 말해주세요
Recoil의 특징, Redux와의 차이점 Recoil의 특징
1. 애플리케이션 전역 상태를 Atoms 라고 불리는 단위로 관리합니다. 이 원자 상태는 여러 컴포넌트에서 읽고 쓸 수 있습니다.
2. React의 함수 컴포넌트에서 선언적으로 상태 정의할 수 있도록 지원합니다.
3. 비동기적으로 데이터 가져올 수 있도록 설계되어 있습니다.
4. 상태를 공유함으로써 컴포넌트 간 느슨한 결합을 촉진합니다. 상태 변화 시 컴포넌트 간 더 쉽게 데이터 공유가 가능합니다.
Redux와의 차이점
1. Redux는 단일 상태 트리이지만 Recoil은 여러 개의 원자를 사용하고, 상태를 더 작은 단위로 분리도 가능합니다.
2. Redux는 액션, 리듀서, 스토어 등 많은 보일러 플레이트 코드를 필요로 하지만 Recoil은 적은 양의 코드로 상태 관리가 가능합니다.
3. 컴포넌트 간 연결이 느슨하여, 대규모 애플리케이션에서 성능 면 우월성을 가집니다.
4. 비동기 상태를 간편하게 다룰 수 있도록 설계되어, 비동기 작업에 유리합니다.
4.버츄얼 돔과 리얼 돔의 차이를 설명해주세요.
DOM은 웹페이지의 구성요소들을 트리구조로 표현한 것이며 가상 돔은 실제 DOM과 구조가 완벽히 동일한 복사본 형태입니다. 가상DOM을 이용하면, 실제 DOM을 조작하는 것보다 메모리상에 올라와있는 javascript 객체를 변경하는 작업이 훨씬 더 가벼우며 뿐 만아니라, 리액트가 버전업테이트를 하면서 가상DOM에서 batchupdate가 가능해졌는데, 예를 들어 인스타그램에서 좋아요를 누르기전과 누른 후를 생각해 본다면, 좋아요를 누르면, 화면에 있는 5개의 엘리먼트가 바뀌어야 한다면 실제 DOM은 5번의 화면 갱신이 필요하지만, 가상 DOM에서는 Batch Update로 인해 단 한번만 갱신이 필요하다는 큰 차이가 있다.
5.useRef에 대해 설명해주세요.
useRef는 React에서 참조(ref)를 생성하고 관리하기 위한 React Hook중 하나입니다. useRef를 사용하면 컴포넌트 내부에서 생성한 변수나 DOM 요소에 대한 참조를 생성하고, 이를 다른 곳에서 사용할 수 있습니다. useRef는 DOM 요소에 직접 접근할 때 사용할 수도 있지만, 그 외에도 여러 상황에서 유용합니다. useRef를 사용하여 생성한 참조는 컴포넌트가 리렌더링될 때마다 새로 생성되지 않으며, 기존에 생성한 참조를 그대로 유지합니다. useRef를 사용하는 상황으로는 다음과 같은 것들이 있습니다.
1) DOM 요소에 직접 접근해야 하는 경우 예를 들어, 특정 DOM 요소의 크기나 위치를 측정하거나, 입력 폼의 값을 가져오거나, 스크롤 위치를 제어하는 등의 작업을 할 때 사용합니다.
2) 컴포넌트 내부에서 생성한 변수나 객체를 관리해야 하는 경우 예를 들어, 특정 상태 값을 저장하고 유지하거나, 이전 값과 새로운 값을 비교해야 하는 경우에 사용합니다.
3) 다른 Hook에서 사용하기 위해 참조를 전달해야 하는 경우 예를 들어, useEffect Hook에서 생성한 함수에서 참조할 변수를 전달하기 위해 사용합니다.
6.useEffect의 실행 순서에 대해 설명해주세요.
1. 컴포넌트 랜더링 : React 컴포넌트는 먼저 랜더링 된다. 이때 JSX를 반환시키고 DOM에 반영된다.
2. useEffect 실행: 컴포넌트 렌더링이 완료 된 후 useEffect 내부의 함수가 실행된다. 이 함수는 비동기적으로 실행될 수 있기 때문에 비동기 작업을 수행하는데 유용하다. * Dependency Array가 있을 때는 해당 dependency array의 값이 변경될 때마다 useEffect가 실행된다
3. clear : 컴포넌트가 unMount 될 때 실행되는 함수로 사이드 이펙트를 정리하는데 사용된다.
7.var, let, const의 차이에 대해 알려주세요.
var와 let, const의 차이는 호이스팅과 스코프의 차이이다. 호이스팅이란 스코프의 런타임 이전에 모든 변수의 선언이 일어난다는 것인데 이는 자바스크립트의 특징이다;. 이러한 특징 때문에 var를 통해 변수를 선언하면 순서마다 진행되야하는 순차적으로 실행되어야 하는 자바스크립트의 실행 컨텍스트 환경에서 코드상 변수 선언 이전에 오류를 발생하지 못하는 문제점이있다. ES6에서는 let과 const는 TDZ(Tempopral Dead Zone)이라는 개념을 도입하여 이러한 런타임 이전 호이스팅이 발생하는 것을 막아주며, let은 변수 const는 상수의 개념을 도입하였다.
8.Async/Await와 Promise의 차이에 대해 설명해주세요
Async/Await는 ES8에서 도입된 비동기 처리 방식 문법으로 함수 내에서 await 키워드를 사용하여 비동기 작업이 끝날 때까지 기다립니다. Async/Await를 사용하면 코드가 간결해지고 가독성이 좋습니다.
Async/Await는 try/catch로 에러를 처리합니다.
Async/Await는 Promise객체를 반환합니다 (then()을 사용 가능)
Promise는 비동기 작업을 다룰 때 사용하는 객체입니다
비동기 작업이 끝나면 성공(resolve) 또는 실패(reject)를 알려줍니다.
Promise는 .catch()를 사용하여 에러를 처리합니다. 작업이 성공 시에는 .then()을 통해 성공 시 처리할 코드를 실패 시에는 .catch()를 통해 실패 시 처리할 코드를 작성합니다.
9.데이터 10,000개를 가지고 무한 스크롤 구현시에 가장 중요하게 고려해야 할점은 무엇인가요?
1. 데이터 조회 방식: 10,000개의 데이터를 한 번에 로드하는 것은 비효율적이며, 성능 문제를 일으킬 수 있습니다. 따라서 데이터는 페이지나 개수를 기준으로 나누어서 조금씩 가져오는 것이 중요합니다. 이를 위해 백엔드 API는 페이징(pagination) 또는 커서 기반(cursor-based) 조회를 지원해야 합니다.
2. 스크롤 이벤트 최적화: 스크롤 이벤트는 매우 빈번하게 발생하므로, 이를 효율적으로 처리하는 것이 중요합니다. 이벤트 핸들러 내에서 불필요한 계산을 최소화하고, throttle 또는 debounce 기법을 사용하여 이벤트 처리 빈도를 제한할 수 있습니다.
3. 로딩 상태와 에러 처리: 데이터를 불러오는 동안에는 로딩 상태를 사용자에게 보여주어야 하며, 데이터 조회에 실패한 경우에는 적절한 에러 메시지를 보여주어야 합니다.
4. UI/UX 고려: 사용자가 스크롤을 끝까지 내렸을 때 자동으로 다음 데이터를 불러오는 것이 일반적입니다. 하지만 사용자가 원할 때 데이터를 불러올 수 있도록 '더 보기' 버튼을 제공하는 것도 좋은 방법입니다. 구현 예시로는 react-infinite-scroll-component 라이브러리를 사용할 수 있습니다. 이 라이브러리는 스크롤 이벤트 처리, 로딩 상태 표시 등 무한 스크롤 구현에 필요한 기능을 제공합니다.
10.Javascript의 호이스팅에 대해 설명해주세요.
javascript에서 호이스팅은 변수 선언과 함수 선언이 그들이 속한 스코프의 최상단으로 끌어올려지는 것을 의미합니다.
호이스팅은 javascript엔진이 런타임 이전에 일어납니다. 호이스팅에의해 변수 선언, 함수 선언 전에 사용할 수 있지만 이는 개발자가 의도한 부분이 아닐것이기에 어플리케이션에 오류를 발생시킬 확률이 높습니다.
하지만 ES6에서 추가된 let, const는 호이스팅이 일어나지만 TDZ(temporal Dead Zone)에의해 변수가 선언되기 전에는 참조오류를 발생시킵니다.
11.동기와 비동기의 차이에 대해 설명해주시고 비동기프로그래밍의 필요성에 대해 답변해주세요.
동기는 프로그래밍을 할 때 앞에 함수가 끝나기 전까지 기다렸다가 다른 함수가 실행시키는 순차적인 작업을 의미하고, 비동기는 객체 또는 이벤트가 완료될 때까지 기다리지 않고 발생하는 여러 관련 작업을 할 수 있는 방식입니다
예를 들어, 카페에서 주문을 받을 때 한 손님이 주문을 하고 메뉴를 준비할 때까지 다음 손님을 받지 않으면 손님은 점점 늘어나고, 뒤에 손님이 만드는 시간이 더 짧은 메뉴를 시킬거라도 앞에 손님이 끝날때까지 기다려야 하기 때문에 비효율적으로 일 처리가 진행될 것입니다
이처럼 동기적으로 처리될 경우 많이 무거운 작업을 수행중일 때는 그 뒤의 어떤 작업도 진행되지 않기에, 화면 로딩, 통신 연결 등의 비효율적이고 사용성 또한 급격히 떨어집니다. 그렇기 때문에 비동기적 방식을 이용해 해야할 일을 위임하고 기다리면서 기다리는 동안 다른 일을 처리할 수 있도록 유동적이고 효율적으로 처리해야합니다
12.브라우저의 작동방식에 대해서 설명해주세요.
브라우저는 사용자가 선택한 자원(Resource)을 서버에 요청(Request)하고, 서버로부터 받은 응답(Response)을 브라우저에 렌더링(Rendering)합니다. 사용자가 브라우저를 통해 찾고 싶은 웹 페이지의 URL주소를 입력하면 DNS서버에서 사용자가 입력한 URL 주소 중 도메인 네임을 검색하고, 도메인 네임에 일치하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달합니다. 이렇게 전달 받은 IP 주소와 웹페이지 URL 정보는 HTTP 프로토콜을 사용해 HTTP 요성 메세지를 생성합니다.
이 HTTP 요청 메세지는 TCP 프로토콜을 사용해 인터넷을 거쳐 해당 IP 컴퓨터로 전송되고, 도착한 HTTP 요청 메세지는 HTTP 프로토콜을 이용해 웹페이지 URL 정보로 변환합니다. 이 변환된 정보에 해당하는 데이터를 검색하여 찾아낸 뒤, HTTP 응답 메세지를 생성하는데, 이 HTTP 응답 메세지는 다시 TCP 프로토콜을 사용해 인터넷을 거쳐 사용자의 컴퓨터로 전송이 됩니다.
도착한 HTTP 응답 메세지는 HTTP 프로토콜을 이용해 웹페이지 데이터로 변환되고, 이 변환된 데이터가 웹 브라우저에 출력 되어 사용자가 볼 수 있게 됩니다.
13.GET, POST 방식의 차이점에 대해서 설명해주세요.
Get은 가져온다는 개념이고, Post는 수행한다는 개념입니다. GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에 동일한 요청을 여러 번 전송해도, 동일한 응답이 돌아온다는 것을 의미합니다.
그래서 GET은 서버의 데이터나 상태를 변경시키지 않아야 하기 때문에, 주로 데이터를 조회할 때 사용해야 합니다. 예를 들어, 브라우저에서 웹 페이지를 열거나, 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청합니다.
POST는 Non-idempotent하기 때문에, 서버에 동일한 요청을 여러 번 전송해도 각기 다른 응답을 받을 수 있으며 POST는 서버의 상태나 데이터를 변경시킬 때 사용됩니다. 게시글을 쓰면 서버에 게시글이 저장되고, 게시글을 삭제하면 해당 데이터가 삭제되는 등 서버에 변화를 일으키는데 됩니다.
이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT, 삭제는 DELETE가 용도에 맞는 메소드라고 할 수 있습니다. Get방식 - 캐싱 가능 - 데이터를 Header(헤더)에 포함하여 전송 - URL에 변수(데이터)를 포함시켜 요청 - 파라미터에 내용이 노출되기 때문에 보안 취약 - 브라우저 기록 생성 - 북마크 추가 가능 - 데이터 길이 제한 POST방식 - 캐싱 불가 - URL에 변수(데이터)를 노출하지 않아 기본적인 보안 보장 - 데이터를 Body(바디)에 포함하여 전송 - 브라우저 기록 생성 불가 - 북마크 추가 불가 - 데이터 길이 대한 제한 무
14.GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.
GET과 POST는 HTTP 프로토콜의 두 가장 기본적인 요청 메서드로, 웹에서 데이터를 전송하는 방식이 다릅니다. GET 요청은 주로 서버로부터 정보를 검색하는 데 사용됩니다. 유저가 url을 입력하거나 링크를 누르게 되면, 브라우저는 URL에 전송할 데이터(쿼리 스트링)를 담아 서버에 HTTP GET 요청을 보냅니다.
(예: http://example.com/index.html?param1=value1¶m2=value2). 요청을 받은 서버는 URL에 포함된 쿼리 스트링에 맞춰 데이터를 처리하고, 이를 HTTP 응답으로 클라이언트에게 보냅니다. 반면에, POST 요청은 서버에 데이터를 제출하여 처리를 요청할 때 사용됩니다.
이 메서드는 데이터를 HTTP 요청의 본문(body)에 포함하여 전송합니다. 사용자가 웹 폼에 데이터를 입력하고 제출 버튼을 클릭하게 되면, 브라우저는 입력된 데이터를 HTTP 요청 본문에 포함하여 서버에 HTTP POST 요청을 보냅니다. 서버는 요청 본문에 포함된 데이터를 처리하고, 필요한 작업(데이터베이스 저장, 로직 처리 등)을 수행한 후, 완료되면 처리 결과를 HTTP 응답으로 클라이언트에게 보냅니다.
15.쿠키, 세션, 웹스토리지의 차이를 설명해보세요.
[쿠키] 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다. 작은 데이터 조각을 클라이언트의 브라우저에 저장하여 정보를 유지하거나 추적합니다. 사용자가 따로 요청하지 않아도 모든 HTTP 요청에 자동으로 포함되어 서버로 전송됩니다. [세선] 사용자의 상태를 서버 측에서 유지하기 위해 사용됩니다.
서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하고 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다. 데이터는 클라이언트로 직접 전송되지 않고, 세션 ID만이 쿠키를 통해 전송됩니다.
[웹스토리지] 로컬스토리지, 세션 스토리지 2가지가 있다. 클라이언트 측에서 데이터를 임시 또는 영구적으로 저장하기 위해 사용됩니다. 데이터를 어딘가에 저장해야 하지만 저장할 데이터가 별로 중요하지 않는 경우 서버에 데이터를 저장하는 것이 낭비일 수도 있습니다. 이럴 때 웹 스토리지를 사영합니다. 로컬 스토리지는 영구적으로 세션 스토리지는 브라우저 세션이 유지되는 동안만 데이터를 저장합니다. 웹 스토리지 데이터는 자동으로 서버로 전송되지 않고, JavaScript를 사용하여 제어됩니다.
16.클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)의 개념에 대해 설명해주시고, 장/단점을 설명해주세요.
클라이언트 사이드 렌더링(CSR)은 웹 애플리케이션에서 페이지의 초기 로드 후에 추가적인 데이터를 받아와서 동적으로 렌더링하는 방식이고, 초기 HTML은 정적으로 제공되며,
JavaScript를 사용하여 클라이언트에서 동적으로 컨텐츠를 렌더링합니다.
장점은:초기 페이지 로드 시 필요한 최소한의 HTML, CSS, JavaScript만 전달되므로 초기 로딩이 빠르고,페이지가 로드된 이후에도 JavaScript를 사용하여 데이터를 비동기적으로 가져와 동적으로 업데이트할 수 있습니다.
단점은:초기 HTML에 동적으로 렌더링되는 컨텐츠가 포함되지 않기 때문에 검색 엔진 최적화에 어려움이 있을 수 있고,초기 로드 이후에 추가적인 데이터를 받아오기 때문에, 초기 로딩 이후의 지연이 발생할 수 있습니다. 사이드 렌더링(SSR)은 서버에서 완전한 HTML을 생성하여 클라이언트에게 전송하는 방식이고,서버에서 렌더링된 HTML을 받아와서 화면에 표시합니다.
장점은:검색 엔진은 서버에서 렌더링된 완전한 HTML을 수용하기 때문에 SEO에 유리하고, 사용자가 페이지를 요청할 때 서버에서 이미 렌더링이 완료된 HTML을 제공하므로 초기 로딩이 빠릅니다. 단점은:매 요청마다 서버에서 새로운 HTML을 생성해야 하므로, 전체적인 성능 면에서 클라이언트 사이드 렌더링보다 느릴 수 있고,많은 사용자가 동시에 서버에 접속하는 경우 서버 부하가 증가할 수 있습니다.
'Today I Learned (TIL)' 카테고리의 다른 글
| 24.01.30 최종 프로젝트 배포 후 추가 수정 중 (1) | 2024.01.30 |
|---|---|
| 24.01.29 배포후 긴급수정 (0) | 2024.01.29 |
| 24.01.27 스토리지 연결....!!! (0) | 2024.01.27 |
| 24.01.26 모의 기술 면접 피드백 정리 (1) | 2024.01.26 |
| 24.01.25 이미지 업로드 대참사 (수파베이스) (0) | 2024.01.25 |
