[주특기 과제]

 

🔐 자바스크립트에서 유사배열과 배열의 차이는 무엇일까요?

유사배열의 각 요소를 수정하고 싶다면 어떤 과정을 거쳐야할까요?

 

배열 :

하나의 변수에 할당해 관리하기 위해 사용하는 데이터 타입이다。

 

유사 배열 :

배열과 유사한 객체를 말한다.

 

유사 배열은 함수에서 처리 결과로 배열을 반환하고 싶을 때 또는, Array에서 기본으로 내포되어있는 기능을 제공하고 싶지 않거나 Array에 내포되어있지 않은 기능을 제공하고 싶을 때 사용한다.

 

1. 숫자 형태의 indexing이 가능할 것

2. length 속성을 포함할 것

수정 과정:

1-1. 간접호출 활용

1-2. Rest파라미터 활용

1-3. Array.from 메서드 활용

등을 활용하여 배열로 변환시켜 준 뒤 요소를 수정한다.

 

🔐 부모 컴포넌트 A와 자식 컴포넌트 B가 있습니다. 컴포넌트 A는 state로 {name: "르탄이"}를 가지고 있고, 자식인 컴포넌트 B에게 name 값을 넘겨주었습니다. 컴포넌트 B는 받아온 name을 화면에 뿌려주고 있습니다.

컴포넌트 A의 state가 {name: "진도사우르스"}로 바뀌었을 때, 어떤 과정을 거쳐 바뀐 값을 화면에 보여주는 지 라이프 사이클 흐름을 그려볼까요?

 

라이프 사이클 : 컴포넌트가 렌더링을 준비하는 순간부터, 페이지에서 사라질 때까지 과정

- 컴포넌트는 생성되고 -> 수정(업데이트)되고 사라진다

- 생성은 처음으로 컴포넌트를 불러오는 단계입니다

- 수정(업데이트) 되는 경우

1) props가 바뀔 때

2) state가 바뀔 때

3) 부모 컴포넌트가 업데이트 되었을 때 ( 리렌더링 했을 때 )

4) 강제로 업데이트를 했을 경우 ( forceUpdate() )를 통해 강제로 컴포넌트를 업데이트 할 수 있다

-제거는 페이지를 이동하거나, 사용자의 행동 (삭제 버튼 클릭)으로 인해 컴포넌트가 화면에서

사라지는 단계입니다)

 

----- 라이프 사이클 흐름 -----

 

- **Mounting**: 컴포넌트가 화면에 나타남

 

### Mounting

 

컴포넌트의 인스턴스가 생성되어 DOM 상에 삽입되는 단계입니다. Mounting은 Lifecyle이 종료될 때까지 한 번만 일어납니다. 아래 메서드들이 이 단계에서 순서대로 호출됩니다.

 

· **constructor**: 컴포넌트의 인스턴스를 새로 만들 때마다 생성자 메서드가 호출됩니다.

 

· static getDerivedStateFromProps

 

· **render**: 화면에 표현될 JSX를 반환하고 화면에 그립니다.

 

· **componentDidMount**: 컴포넌트가 화면에 모두 그려진 이후 호출됩니다.

 

componentDidMount 메서드는 첫 렌더링 이후 실행됩니다. 엔드포인트에서 클라이언트로 데이터를 불러와야 하는 경우라면, API 호출을 하기 좋은 위치입니다. 데이터를 받아 올 때 setState 메서드를 이용하여 컴포넌트를 업데이트할 수 있습니다.

 

- **Updating**: 컴포넌트가 업데이트됨

 

### Updating

 

props 또는 state가 변경되어 컴포넌트가 업데이트되는 단계입니다. 아래 메서드들이 이 단계에서 순서대로 호출됩니다.

 

· static getDerivedStateFromProps

 

· shouldComponentUpdate

 

· **render**: 데이터가 변경되면 자동으로 호출됩니다. 화면을 다시 그립니다.

 

· getSnapshotBeforeUpdate

 

· **componentDidUpdate**: 화면이 다시 그려진 이후 호출됩니다.

 

- **Unmounting**: 컴포넌트가 화면에서 사라짐

 

### Unmounting

 

컴포넌트가 DOM 상에서 제거되는 단계입니다.

 

·**componentWillUnmount**: 컴포넌트가 화면에서 제거되기 전에 호출됩니다.

 

 

### 흐름 설명

 

컴포넌트 A에서 “르탄이”라는 state를 “진도사우르스” 변경 ->

 

부모 컴포넌트에서 Updating이 발생 ->

 

shouldComponentUpdate 가 실행 ->

 

바뀐 props를 이용하여 부모 컴포넌트의 렌더링 ->

 

마찬가지로 바뀐 props를 이어받아 컴포넌트 B의 렌더링이 실행됨

 

 

 

🔐 양방향 바인딩은 무엇일까요?

양방향 바인딩을 사용하는 경우 리렌더링이 어떻게 이루어질 지 그려보세요.

(부모 컴포넌트 A와 자식 컴포넌트 B가 있음을 가정하고 그려봅시다.)

 

데이터 바인딩이란?

두 데이터 혹은 정보의 소스를 일치시키는 기법으로, 화면에 보이는 데이터와 브라우저 메모리에 있는 데이터(여러개의 자바스크립트 객체)를 일치시키는 것을 말한다.

 

양방향 데이터 바인딩

 

장점 : 코드의 사용면에서 코드량을 크게 줄여줌

단점 : 변화에 따라 DOM 객체 전체를 렌더링해주거나 데이터를 바꿔주므로, 성능이 감소되는 경우가 있음

컨트롤러에서 model이 변경됨 -> view변경됨

view에서 scope model이 변경됨 -> 컨트롤러에서 model이 변경됨

 

이렇게 컨트롤러와 뷰 양쪽의 데이터 일치가 모두 가능한 것이 양방향 데이터 바인딩이다. 데이터의 변화를 감지해 템플릿과 결합해 화면을 갱신, 화면의 입력에 따라 데이터를 갱신하는 것이다. (HTML -> JS, JS -> HTML 양쪽 모두 가능)

 

양방향 데이터 바인딩은 데이터의 변경을 프레임워크에서 감지하고 있다가, 데이터가 변경되는 시점에 DOM 객체에 렌더링을 해주거나 페이지 내에서 모델의 변경을 감지해 JS 실행부에서 변경한다. 입력된 값이나 변경된 값에 따라 내용이 바로 바뀌기 때문에 따로 체크해주지 않아도 된다.

 

양방향 데이터 바인딩은 웹 애플리케이션의 복잡도가 증가하면 증가할수록 빛을 발한다. 수많은 코드의 양을 줄여줄 뿐만 아니라 유지보수나 코드를 관리하기 매우 쉽게 해주기 때문이다.

 

 

 

 

🔐 event listener는 등록되면 반드시 해제되어야 합니다.

클래스형 컴포넌트에서는 컴포넌트가 화면에서 사라질 때(unmount 될 때) event listener를 해제합니다. (componentWillUnmount에서요!)

그럼 라이프사이클 메소드를 사용할 수 없는 함수형 컴포넌트에서는 event listener를 해제할 때 어떻게 해야할까요?

 

useEffect

함수형 컴포넌트에서는 각각의 라이프사이클 메소드를 useEffect 하나로 통일시킬 수 있다. 대신 dependency를 선언하여 시점을 구분한다.

 

useEffect(() => {

console.log('hi')

}, [/* dependency 선언하는 곳 */])

빈 배열을 선언하면 최초 로드시에만 렌더링이 된다.

 

이벤트 해제하기

이벤트를 등록하고 난 뒤 성능 저하를 방지하기 위해 컴포넌트가 언마운트 될 때 꼭 이벤트 등록을 해제해주어햐 한다. 함수형 클래스에서는 useEffect의 내부 함수의 return값으로 removeEventListener를 통해 해제해주면 된다.

 

useEffect(() => {

document.addEventListener();



return () => {

document.removeEventListener();

}

}, [])

 

 

🔐 리액트에서는 DOM 요소에 접근하기 위해 주로 ref를 씁니다.

domcument.getElementsByClassName 등을 쓰는 게 아니라 ref를 쓰는 이유는 무엇일까요?

 

ref를 사용하는 이유?

id는 유일해야 하지만 컴포넌트 재사용을 한다면 중복될 가능성이 있다.

 

ref는 전역적으로 작동하지 않고 컴포넌트 내부에서만 작동한다.

 

어떨 때 사용해야 하는가?

DOM을 꼭 직접적으로 건드려야 할 때 사용한다.

 

특정 input에 포커스 주기

스크롤 박스 조작하기

Canvas 요소에 그림 그리기 등

 

선언적으로 해결될 수 있는 문제에서는 ref 사용을 지양해야한다.

 

ref의 사용을 최대한 줄여야 한다고 명시되어있다.

 

 

 

 

🔐 SPA 방식과 MPA 방식은 무엇인가요?

 

SPA vs MPA

- SPA(Single Page Application)는 한 개(Single)의 Page로 구성된 Application이다.

MPA(Multiple Page Application)는 여러 개(Single)의 Page로 구성된 Application이다.

- MPA는 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드된다. 매번 전체 페이지가 다시 렌더링 된다.

반면 SPA는 웹 에플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다.

그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다.

- 그래서 SPA를 CSR(Client Side Rendering) 방식으로 렌더링한다고 말한다.

그래서 MPA를 SSR(Server Side Rendering) 방식으로 렌더링한다고 말한다.

 

MPA(Multiple Page Application)

- 여러 개(Single)의 Page로 구성된 Application이다.

- MPA는 SSR(Server Side Application) 방식으로 렌더링한다.

새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JavaScript)가 다운로드된다.

페이지 이동하거나 새로고침하면 전체 페이지를 다시 렌더링한다.

 

👍 MPA 장점

1. SEO 관점에서 유리하다.

- MPA는 완성된 형태의 HTML 파일을 서버로부터 전달받는다.

따라서 검색엔진이 페이지를 크롤링하기에 적합하다.

2. 첫 로딩 매우 짧다.

- 서버에서 이미 렌더링해 가져오기 때문이다.

- 그러나 클라이언트가 JS 파일을 모두 다운로드하고 적용하기전 까지는 각각의 기능은 동작하지않는다.

 

👎 MPA 단점

1. 새로운 페이지를 이동하면 ‘깜빡’인다. (UX)

- 매 페이지 요청마다 리로딩(새로고침) 발생.

새로운 페이지를 요청할 때마다 전체 페이지를 다시 렌더링하기 때문이다.

2. 페이지 이동 시 불필요한 템플릿도 중복해서 로딩 (성능)

3. 서버 렌더링에 따른 부하

4. 모바일 앱 개발 시 추가적인 백엔드 작업 필요 (생산성)개발이 복잡해질 수 있다.