Bong

SPA(Single page application)?

한 개의 페이지로 이루어진 애플리케이션.

• 전통적인 웹 페이지는 여러 개의 페이지로 이루어져 있다.

• 페이지 이동이 이루어질 때 마다. 새로운 html을 받아 해석한 뒤 보여 준다.

  → 웹에서 제공되는 정보가 많아 짐에 따라 서버 측에서 모든 화면을 준비한다면? 성능상 문제가 발생할 수 있다.

  → 캐싱, 압축으로 어느정도 해결 가능하나. 사용자와 인터랙션이 자주 발생하는 모던 웹 어플리케이션은 부적절 하다.

  → html을 계속 서버에 새로 요청하면? 사용자의 상태 유지가 번거롭고 바뀌지 않는 부분도 리 렌더링 하기 때문에 비효율 적이다.

리액트 같은 라이브러리 혹은 프레임워크를 사용하면?

• 렌더링은 브라우저 담당.
• 사용자와 인터랙션이 발생하면 필요한 부분만 js를 통해 업데이트 해준다.
• 새로운 데이터가 필요하다면?
  • 서버 api를 호출 해 필요한 데이터만 새로 불러와 사용한다.

SPA는 화면이 한 종류 일까?

• 서버에서 사용자에게 제공하는 페이지는 한 페이지 이지만 페이지에서 요청된 js 또는 주소에 따라서 다양한 화면을 보여 줄 수 있다.

라우팅

• SPA에서 다른 주소에서 다른 화면을 보여주는 것을 말한다.

SPA의 단점.

앱의 규모가 커지면? 자바 스크립트 파일이 너무 커진다.

• 한번에 모두 받기 때문에, 사용하지 않을 js파일 까지 모두 로딩한다.

  → 코드 스플리팅 으로 개선 가능.

JS를 실행하지 않는 일반 크롤러는 페이지의 정보를 제대로 수집 하지 못한다.

• 구글, 네이버, 다음 등 검색 결과가 제대로 나오지 않는다.

  → SSR (Server Side Rendering) 으로 모두 해결 가능.

Single-page Application, SPA란?

기존 웹 방식과는 다르게, 페이지 요청 시 완전히 새로운 페이지를 불러오는 것이 아닌, 동적으로 페이지를 다시 작성해 '사용자와 소통' 하는 웹 애플리케이션 or 웹 사이트를 뜻함.

→ 처음 로드 하고 난 뒤, 새로고침이 없는 것이 특징이다.

장점이 뭐야?

연속적인 페이지 간의 사용자 경험의 간섭을 막아준다.

→ 기존 형태의 웹이 주던 딱딱하고 끊기는 느낌을 사용자에게 주는 것이 아니라. 애플리케이션처럼 부드럽고 자연스러운 사용자 경험 (UX)을 느끼게 해 준다.

→ SPA의 최대의 목적은 뛰어난 사용자 경험을 준다는 것이다.

필요한 리소스만 부분적으로 로딩

→ 페이지의 모든 정보를 가져오는 것이 아닌, 화면 구성에 필요한 정보만 동적으로 요청을 해서 화면을 변경하는 방식으로 사용한다.

→ 필요한 부분만 요청하는, 데이터를 적게 사용하는 방식이기 때문에, 모바일 네트워크에서도 빠른 속도로 렌더링이 가능하다.

서버의 연산 부담을 클라이언트로 분산

→ 최초의 http 요청을 통해 딱 한 번만 http, Css, javascript를 로딩. 이후 데이터를 받아 올 때만 서버와 통신.

→ 통신된 데이터를 통해 기존 페이지의 내부를 수정해서 보여주는 방식.

컴포넌트로 나누어서 개발함으로 관리적 용이성

→ 모던 웹 들은 계속 다채로워지고 화려해지고 있다. ( 점점 복잡해진다!)

→ 많은 컴포넌트 ( 홈페이지에서 각각의 아이템들이라고 생각하면 편하다. 메뉴창, 내비게이션 바 등..)를 분리해서 관리를 함.

→ 데이터 변경이 있어 화면을 재 구성해야 하는 경우 전체를 바꾸는 것이 아닌, 컴포넌트 단위로 화면을 갱신.

단점이 뭐야?

초기 구동 속도가 느리다.

→ SPA의 단점 이라기보다 SPA구조 상 어쩔 수 없는 상황이다. SPA는 초기에 웹에 필요한 대부분의 리소스를 다운로드한다.

→ 이러한 손해를 감수하고도 얻고자 하는 것은 전체적인 속도 , 반응성, 사용성을 추구하기 위함이다. 하지만 우리는 어찌 되었든 메인 페이지는 빠르게 뜨길 원한다면?

1. Lazyload
   • 많은 양의 코드 (초기 다운로드)를 작은 양의 개별 작업으로 분할시켜 제공하는 방법.
   • Code splitting.
   • Route-based code splittig

검색엔진 최적화(SEO)가 어렵다.

→ 이 문제는 js기반 비동기 연동 모델로 작동되는 모든 웹 환경에서 문제가 생긴다.

→ SPA가 극단적으로 js를 사용하다 보니 더욱 부각되는 것뿐이다.

→ 대부분의 서치 봇 들이 html을 파싱 해서 정보를 만든다. 그렇기 때문에 SPA와 같이 html의 뼈대 위에 js 비동기 통신 모듈을 통해 내용을 채우는 방식을 사용하면, 서치 봇이 제대로 감지를 못하는 상황까지 이른다.

—> 이를 해결하기 위해서 SSR (Server SIde Rendering)이라는 방식으로 사용되고 있다.

그래서 SPA는 좋은 거야?

이에 대한 정답은 없다고 생각한다. 어떠한 기술을 바라볼 때, 항상 좋은 점만 있는 것은 아니다.

SPA와 기존 고전 웹의 특징을 잘 비교 한 뒤 본인이 만들 웹 페이지에 기획과 콘셉트에 맞게 스스로 고민하고 선택하는 것이 중요하다고 생각한다.

React 이전

Jquery , Backbone, AngularJS

2006년 Jquery 등장 이후 Dom을 다루는 형식으로 표준 처럼 사용되었다.

Backbone과 AngularJS역시 돔을 다루는 중요한 방법으로 Jquery 사용.

React 등장

• Facebook이 만든 Javascript 라이브러리
• Facebook, Netflix, Dropbox, Twitter, Evernote, Uber 등 많이 사용함.
• View 라이브러리이다.

그래서 왜 React가 나왔는데?

• 기존 웹 프로젝트가 거대해지면, 코드의 양도 자연스럽게 증가

  → 기존 html, js 코드들이 분리되지 않기에 코드 가독성이 매우 낮아짐.

  → 관리의 효율이 매우 떨어진다.

• React는 Component와 Module로 어느정도 해결.

  → 뚜렷한 의미를 가지는 클래스들의 모듈화!

Component

• Ui를 구성하는 개별적인 뷰 단위.
• Component들이 결합되어 앱이 탄생.
• Component의 핵심은 쉽게 재사용이 가능하게!

→ 복잡한 화면을 각자의 개념으로 작은 단위로 쪼개고, 해결한 뒤, 다시 합쳐 해결!

→ 개념으로 쪼개다?? : 해결하는 방법을 각자가 가지고 있고 외부에서는 알 필요가 없다.

Jsx

• React를 위해 태어난 새로운 js문법.
• 기존 js는 화면을 표현하기 불편하기 때문에 등장.

Virtual DOM

• 이것을 가능하게 해주는 것이 Virtual Dom이다.

1. React Component 는 Render를 호출. 결과값을 Return한다.
2. React 는 새로운 Return 값을 가지고 새로운 Virtual DOM을 생성.
3. 현재 브라우저에 보여지고 있는 진짜 DOM과 비교하여 차이점을 찾아냄.
4. 차이점이 새긴다면 실제 Virtual DOM → DOM 적용.