프론트엔드 스터디 - 2

웹표준

• 정의: 웹에서 표준적으로 사용되는 기술이나 규칙, 어떤 운영체제나 브라우저를 사용하더라도 웹페이지가 동일하게 보이고 정상 작동해야함을 의미
• 웹표준을 잘지킨다 ⇒ W3C의 권고를 따라 HTML,JS,CSS를 코딩하고, 문서 객체 모델(DOM)또한 원칙에 따라 구조화를 잘 시킨 것

크로스 브라우징 이슈의 발생원인과 문제점 해결방안

• 원인: 브라우저마다 렌더링 엔진이 다르기 때문에 발생한다.
  • 파이어폭스 : 게코
  • 사파리 : 웹킷
  • 크롬 : 블링크
• 문제점
  • 작동되지 않는 HTML, Javascript 코드가 존재 (IE replaceAll)
  • 브라우저마다 자체적인 기본 css 스타일, 해석하지 못하는 CSS 코드 존재 (사파리 gap)
• 해결방안 : 어떤 브라우저를 사용하더라도 웹페이지가 동일하게 보이고 정상 작동하게 만듬
  • 보수적으로 코드를 작성. 모든 브라우저에서 작동하는 코드. 어쩔 수 없다면 점유율이 높은 브라우저 순서
  • reset.css 를 사용해서 초기값 공통. 브라우저 별 초기 차이점을 상쇄
  • jquery(잘안쓰임), pollyfill 같은 라이브러리를 사용
  • IE에서 - IE 용 주석을 이용한 방법
  • CSS, 브라우저 접두사 사용 ex) webkit- 구글, 사파리

반응형웹과 적응형 웹

• 적응형 : 미리기기 사이즈를 정의해두고 사이즈에 맞게끔 웹 페이지를 고정시켜서 준비하는 것이다. 정해놓은 기기의 사이즈가 되면 미디어 쿼리나 스크립트를 활용해서 레이아웃을 변경하여 화면을 구성하는 방법이다.
  • 장점: 하나 개발할때마다 하나의 기기 사이즈에만 집중하면 되고 개발이 용이하다.
  • 단점: 코드 변경 시 해상도별 업데이트가 필요하기 때문 유지보수가 힘들다.
• 반응형 : 고정되어있지 않고, 화면의 크기에 따라 페이지의 사이즈가 변화한다. PC / 태블릿 / 모바일 각각의 전용 홈페이지를 만들 필요가 없다. 주로 %를 사용한다.
  • 장점: 하나의 소스를 수정하면 모든 기기 사이즈에 맞추어 콘텐츠가 최적화되므로 유지보수가 효율적이다.
  • 단점: 고정된 픽셀값 대신 백분율 값을 사용하고 기기화면 크기에 따라 조정해야 되기 때문에 코드가 복잡해질 수 있다.

반응형웹의 구현방법

• 절대적 단위 대신 상대적 단위를 사용해야 한다. 요소의 침범, 해상도에 따른 문제점이 생길 수 있기 때문에 px을 지양하는게 좋다. px대신 % 또는 em, rem을 사용한다.
  • px, em, rem 의 차이점: em과 rem은 가변단위로서 브라우저 환경에서 px로 변환된다. em은 같은 엘리먼트에서 지정된 font-size를 기준으로 px로 바뀌어 화면에 표시된다. 같은 엘리먼트에 설정된 폰트 크기 값이 없을 경우, 상위 요소의 폰트 사이즈가 기준이 된다. rem은 최상위 엘리먼트에서 지정된 font-size의 값을 기준으로 변환된다. 대개는 HTML tag에서 지정된 font-size가 기준이 된다. 만약 별도의 font-size를 설정하지 않은 경우에는 각 브라우저에서 기본적으로 설정된 값을 상속 받는다. 일반적으로 폰트 사이즈는 rem, 나머지 padding같은 것들은 em 한다.
• max-width와 min-width를 사용한다.
  • max-width: 800px (800이상으로 안커짐)
• media query를 사용한다.
  • @media screen and (min-width:480px) and (max-width:768px)
• flex, grid와 같은 layout을 사용한다.
• viewport 를 설정해준다.
  • 데스크탑에서 모바일로 이동하면서 비율이 맞지 않는 문제 ⇒ 풀브라우징 지원: viewport 980px ⇒ 작은 화면의 모바일 단말기에 웹 페이지 모두를 표시하려고 하니 전체적인 페이지의 배율이 조정. 너무 오밀조밀 ⇒ meta태그 viewport 설정 ⇒ 다양한 모바일 기기에서도 페이지의 너비나 화면 배율을 설정. 기기에 딱 맞게 설정
• img 는 srcset 속성을 사용해 width별 이미지 표시(파이어폭스만 지원) , sizes 속성(미디어쿼리처럼), picture 태그 웹표준이됨. 모든 브라우저에서 지원.

<picture>
	<source srcset="/image/logo180.jpg" media="(max-width: 768px)">
	<img src="/image/logo360.jpg" alt="logo" /> //기본
</picture>

• js : window객체 matchMedia메서드로 화면 크기, navigator객체의 useragent 프로퍼티에 기기정보

web1.0, web2.0 web3.0

• web1.0 : 초기의 웹. 콘텐츠 없이 단순한 정보만을 포함한 정적 웹사이트의 집합이다. 단순히 전송을 받고 읽을 수만 있다. TCP/IP 또는 http 같은 오픈소스 프로토콜을 사용한다.
• web2.0 : 바라보기만 하는 웹이 아닌 참여하는 웹이다. 기업들은 웹1의 오픈소스 프로토콜 위에 본인들만의 폐쇄프로토콜 만들었다.(롤을 하는 사람 카톡을 하는 사람 연결x 각각 해당 서비스 내에서 폐쇄적으로 연결, 연결시키려면 api가 필요) 이렇게 앱, 웹이 만들어졌고 누구나 컨텐츠를 쓰고 만들 수 있게 되었다. 범지구적 정보공유가 이루어지고 소셜 미디어 시대가 열리게되었다. 중앙화에서 나오는 해킹의 위험성(페이스북 해킹사태)과 개인 프라이버시의 문제가 있다. web2.0은 각 기업들은 중앙화된 ,자신들만의 서버에 데이터(개인정보를)를 대량으로 적재하기 시작함 이것을 상업적인 용도로 사용하기도 했다
• web3.0 : web2.0이 오픈소스 프로토콜 위에 폐쇄프로토콜을 올린 형태라면, web3.0은 오픈소스 프로토콜위에 또 다른 오픈소스 프로토콜을 올린 형태이다. 오픈소스 프로토콜이란 블록체인을 의미한다. 프로토콜을 기업이 컨트롤하지 않게되고 탈중앙화가 이루어진다. 웹2에서의 문제점을 해결할 수 있다. 공개 프로토콜이며 블록체인으로 연결이 될 수 있기 때문에 한게임에서 사용하는 골드를 다른게임으로 바로 이동. NFT로 저장만 되어있다면. 이러한 연결이 바로 메타버스
  • nft(non fungible token): 대체불가능한 토큰 / 비트코인은 fungible token
• 정리: web1(오픈소스 프로토콜), web2(오픈소스 프로토콜+ 폐쇄형 프로토콜), web3(오픈소스프로토콜 + 오픈소스 프로토콜)

디바운스와 쓰로틀

• 배경: scroll, resize, mousemove 같은 이벤트는 짧은 간격으로 연속해서 발생한다. 이러한 이벤트는 과도하게 호출되어 성능에 문제를 일으킬 수 있다.
• 디바운스: 짧은 간격으로 이벤트가 연속해서 발생하면 이벤트 핸들러를 호출(call)하지 않다가 마지막 이벤트 호출로부터 일정 시간이 경과된 이후에 이벤트 핸들러가 한 번만 호출되도록 한다. resize 이벤트 처리, input에 따른 이벤트, 버튼 중복 클릭 방지에 사용될 수 있다.
• 쓰로틀: 쓰로틀은 짧은 시간 간격으로 연속해서 발생하는 이벤트를 그룹화해서 일정 시간 단위로 이벤트 핸들러가 호출되도록 호출 주기를 만든다. 쓰로틀은 scroll 이벤트 처리나 무한 스크롤 UI 구현 등에 사용된다.

CSR VS SSR

• html이 어디서 완성되냐.
• csr : 빈 html과 js코드들이 클라이언트로 다운된다. 그 다음 js를 실행하고 동적으로(API호출, 이벤트 호출) DOM에 내용을 추가하면서 그린다.
• ssr: 서버에서 데이터가 추가된, 즉시 렌더링 가능한 html 파일을 만들어서 브라우저로 전달하고 브라우저는 바로 렌더링한다.
• (일반적으로) 첫 페이지 로딩 시간: csr(모든 리소스를 처음에 다운) < ssr(필요한 부분의 리소스만 불러옴)
  • 꼭 그럴까? (클라컴은 엄청 좋고, 서버컴은 엄청 구리다면?)
• 첫 페이지 이후 로딩 시간 : csr(필요한 부분만 실행되고 변경 > ssr(불필요한 부분까지 다시 렌더링)
• seo : csr(빈 html, 크롤러가 찾지 못함) < ssr (완성된 html) ⇒ 구글 예외다.
• 서버 부하 : csr < ssr(SSR이 서버 자원을 더 많이 사용한다. 매번 서버에 요청을 하기 때문이다.)

SPA VS MPA

• SPA : 한 개의 Page로 구성된 Application. SPA는 웹 에플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다.그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다.
• MPA : 여러 개의 Page로 구성된 Application. MPA는 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드된다. 매번 전체 페이지가 다시 렌더링 된다(깜빡임)
  • SPA CSR 같은 개념? 아님. CSR, SSR은 html이 어디서 완성되는가, spa와 mpa는 페이지의 개수.
  • SPA+SSR의 장점을 합친 Next js도 있음.

NEXT JS 를 사용하는 이유

• SEO를 하기 위해 (가장큼)

  NEXT를 사용하면 사용자가 초기에 Server에 페이지 접속을 요청했을 때 SSR방식으로 렌더링 될 HTML을 보내줌으로써 SEO의 장점을 가져가는 동시에 이후에 사용자가 페이지와 상호작용을 할 때는 CSR방식으로 브라우저에서 처리함으로써 SPA 의 장점 또한 가진다.
  

• 코드 스플리팅 지원 : 스크립트 코드가 분할되서 사용되는 페이지와 함께 제공. 결과적으로, 불필요한 코드가 페이지에 로드되지 않게 되고 필요한 부분만 가져옴.

• 설정의 용이함 : 넥스트는 기본적으로 웹팩과 바벨을 사용, 타입스크립트가 내장됨 설정변경:next.config.js (CRA안하면 번거로움, WEBPACK설정)

• 파일기반 내비게이션 기능 : 리액트에서는 라우트를 위해서 'react-router'라는 라이브러리를 사용하여 라우팅 설정을 해주어야 한다. next는 폴더의 경로에 따라 페이지의 경로가 설정되어 구축이 빠르고 관리가 편리하다는 장점이 있다.

• 구조 (pages 내부)

  • app: app 컴포넌트는 모든 페이지의 공통 페이지 역할을 한다.
    • 페이지들의 공통된 레이아웃
    • 페이지를 탐색할 때 상태 유지
    • 추가 데이터를 페이지에 주입
    • 글로벌 CSS 추가
  • document: 사용자 정의 Document는 일반적으로 응용 프로그램 <HTML> 및 <body> 태그를 보강하는데 사용도된다. document를 이용하여 <title>, <description>, <meta> 등 프로젝트의 정보를 제공하는 HTML 코드를 작성할 수 있고, 폰트나 외부 api, cdn 등을 불러오도록 할 수 있다.
  • error : 넥스트에서는 빌드 된 프로덕션 환경에서 에러가 발생한다면 에러 페이지로 넘어가게 된다. 따로 라우팅 경로를 설정하지 않더라도, 빌드 된 프로덕트 환경에서 에러가 발생한다면 에러 페이지로 자동적으로 넘어간다. 추가적으로 에러 상황에 따라서 500, 404 등도 추가할 수 있다.

• 사전 렌더링

  • getInitialProps
  • getStaticProps
  • getStaticPath
  • getServerSideProps