Javascript의 기본 #3

Javascript와 관련하여 Same-origin 정책을 설명하여라

same-origin 정책은 Javascript가 도메인 경계를 넘어서 요청하는 것을 방지합니다. origin은 URL 체계, 호스트 이름, 포트 번호의 조합으로 정의됩니다. 이 정책은 한 페이지의 악의적은 스크립트가 해당 페이지의 DOM을 통해 다른 웹 페이지의 중요한 데이터에 접근하는 것을 방지합니다.

다음을 작동하게 만들어보아라

duplicate([1, 2, 3, 4, 5]);  // [1,2,3,4,5,1,2,3,4,5]

function duplicate(arr) {
  return arr.concat(arr);
}

duplicate([1, 2, 3, 4, 5]);  // [1,2,3,4,5,1,2,3,4,5]

왜 Ternary expresstion이라고 부르며, 'Ternary'라는 단어는 무엇을 나타내는가?

'Ternary'는 '삼항'을 나타내고, 삼항 표현식은 세가지 피연산자, 테스트 조건문, 'then' 표현식, 'else' 표현식을 받습니다. 삼항 표현식은 Javascript에만 해당되는 것이 아닙니다.

'use strict';이 무엇이고 장단점이 무엇인가?

'use strict'은 전체 스크립트나 개별 함수에 엄격 모드를 사용하는데 사용되는 명령문입니다.
strict 모드는 Javascript의 다양한 문법을 제한하는 방법입니다.

장점

• 실수로 전역변수를 만드는 것이 불가능합니다.
• 암묵적으로 실패한 예외를 throw하지 못하는 할당을 만듭니다.
• 삭제할 수 없는 속성을 삭제하려고 시도합니다.
• 함수의 매개변수 이름을 고유하게 합니다.
• this 는 전역 컨텍스트에서 undefined입니다.
• 예외를 발생시키는 몇 가지 일반적인 코딩을 잡아냅니다.
• 헷갈리거나 잘 모르는 기능을 사용할 수 없게 합니다.

단점

• 일부 개발자는 익숙하지 않는 기능이 많습니다.
• function.caller 와 function.arguments 에 더 이상 접근할 수 없습니다.
• 서로 다른 엄격한 모드로 작성된 스크립트를 병합하면 문제가 발생할 수 있습니다.

전반적으로 장점이 단점보다 더 중요하다고 생각합니다.
엄격 모드가 차단하는 기능에 의존하지 않아도 되니, 사용하는 것을 추천합니다.

100까지 증가하면서 3의 배수에는 fizz를 출력하고, 5의 배수에는 buzz를 출력하고, 3과 5의 배수에는 fizzbuzz를 출력하는 for loop를 만들어보아라

for (let i = 1; i <= 100; i++) {
  let f = i % 3 === 0,
    b = i % 5 === 0;
    
  console.log(f ? (b ? 'FizzBuzz' : 'Fizz') : b ? 'Buzz': i)
}

길지만 분명한 접근 방식을 고수하세요.

일반적으로 웹 사이트의 전역 스코프를 그대로 두고 건드리지 않는 것이 좋은 이유는 무엇인가요?

모든 스크립트는 전역 스코프에 접근할 수 있으며, 모든 사람이 전역 네임스페이스를 사용하여 변수를 정의하면, 충돌이 발생할 수 있습니다.
모듈 패턴(IIFEs)을 사용하여 변수를 로컬 네임스페이스 내에 캡슐화하세요.

왜 load 이벤트를 사용하는가?

load 이벤트는 문서로딩 프로세스가 끝날 때 발생합니다.
이 시점에서 문서의 모든 객체가 DOM에 있고, 모든 이미지, 스크립트, 링크 및 하위 프레임 로딩이 완료됩니다.

DOM 이벤트 DOMContentLoaded 는 페이지의 DOM이 생성된 후에 발생하지만 다른 리소스가 로딩되기를 기다리지 않습니다.
이것은 초기화되기 전에 전체 페이지가 로드될 필요가 없는 경우에 선호됩니다.

single page app이 무엇인지 설명하고 SEO-friendly 하게 만드는 방법을 설명해보아라

웹 개발자는 요즘 웹 사이트가 아닌 웹 앱으로 제작한 제품을 언급합니다.
두 가지 용어 사이에 엄격한 차이는 없지만, 웹 앱은 대화형과 같이 동적인 경향이 있어 사용자가 작업을 수행하고 작업에 대한 응답을 받을 수 있습니다.
전통적으로 브라우저는 서버에서 HTML을 받아 렌더링합니다.
사용자가 다른 URL로 이동하면, 전체페이지 새고고침이 필요하며 서버는 새 페이지에 대해 새 HTML을 보냅니다.
이를 server-side rendering이라고 합니다.

그러나 현대 SAP에서는 대신 client-side rendering이 사용됩니다.
브라우저는 전체 애플리케이션에 필요한 스크립트(프레임워크, 라이브러리, 앱코드) 및 스타일시트와 함께 서버의 초기 페이지를 로드합니다.
사용자가 다른 페이지로 이동하면 페이지 새로고침이 발생하지 않습니다.
페이지 URL은 HTML5 History API를 통해 업데이트됩니다.
일반적으로 JSON 형식의 새 페이지에 필요한 새 데이터는 브라우저에서 AJAX 요청을 통해 서버로 전송됩니다.
SPA는 초기 페이지 로딩에서 미리 다운로드된 javaScript를 통해 페이지를 동적으로 업데이트합니다.
이 모델은 네이티브 모바일 앱의 작동 방식과 유사합니다.

장점들

• 전체 페이지 새로고침으로 인해 페이지 탐색 사이에 하얀 화면이 보이지 않아 앱이 더 반응적으로 느껴지게 됩니다.
• 동일한 에셋을 페이지 로드마다 다시 다운로드할 필요가 없으므로 서버에 대한 HTTP 요청이 줄어듭니다.
• 클라이언트와 서버 사이의 고려해야할 부분을 명확하게 구분합니다.
  서버 코드를 수정하지 않고도 다양한 플랫폼(예: 모바일, 채팅 봇, 스마일워치)에 맞는 새로운 클라이언트를 쉽게 구축할 수 있습니다.
  또한 API 규약이 깨지지 않는 한도 내에서 클라이언트와 서버에서 기술 스택을 독립적으로 수정할 수 있습니다.

단점들

• 여러 페이지에 필요한 프레임워크, 앱 코드, 에셋로드로 인해 초기 페이지로드가 무거워집니다.
• 모든 요청을 단일 진입점으로 라우트하고 클라이언트 측 라우팅이 그 한 곳에서 인계받을 수 있도록 서버를 구성하는 추가 단계가 필요합니다.
• SPA는 콘텐츠를 렌더링하기 위해 Javascript에 의존하지만 모든 검색 엔진이 크롤링중에 Javascript를 실행하지는 않으며 페이지에 빈 콘텐츠가 표시될 수 있습니다.
  이로 인해 의도치 않게 앱의 검색 엔진 최적화(SEO)가 어려워집니다.
  그러나 대부분의 경우 앱을 제작할 때 검색 엔진에서 모든 콘텐츠를 색인할 필요는 없으므로 SEO가 가장 중요한 요소는 아닙니다.
  이를 극복하기 위해 앱을 서버 측 렌더링하거나 Prerender과 같은 서비스를 사용하여 브라우저에서 Javascript를 렌더링하고, 정적 HTML을 저장한 다음, 크롤러에게 반환합니다.