12. Frontend

1. Describe the difference between a cookie, sessionStorage and localStorage

LocalStorage

localStorage is a way to store data on the client’s computer. It allows the saving of key/value pairs in a web browser and it stores data with no expiration date. localStorage can only be accessed via JavaScript, and HTML5. However, the user has the ability to clear the browser data/cache to erase all localStorage data.

Pros:

• stores data with no expiration date
• storage limit is about 5MB
• data is never transferred to the server

Cons:

• plaintext, hence not secure by design
• limited to string data, hence need to be serialized
• can only be read on client-side

Session storage

• stores data only for a session, meaning that the data is stored until the browser (or tab) is closed
• data is never transferred to the server
• can only be read on client-side
• storage limit is about 5-10MB
• opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window

Cookie

• Stores data that has to be sent back to the server with subsequent XHR requests. Its expiration varies based on the type and the expiration duration can be set from either server-side or client-side .
• Cookies are primarily for server-side reading (can also be read on client-side), localStorage and sessionStorage can only be read on client-side.
• Size must be less than 4KB.
• Cookies can be made secure by setting the httpOnly flag as true for that cookie. This prevents client-side access to that cookie.

출처: krishankantsinghal.medium.com/local-storage-vs-session-storage-vs-cookie-22655ff75a8

2. 브라우저 동작 원리에 대해 설명해 보세요

 

브라우저의 핵심 기능은 사용자가 참조하고자 하는 웹페이지를 서버에 요청(Request)하고 서버의 응답(Response)을 받아 브라우저에 표시하는 것이다. 브라우저는 서버로부터 HTML, CSS, Javascript, 이미지 파일 등을 응답받는다. HTML, CSS 파일은 렌더링 엔진의 HTML 파서와 CSS 파서에 의해 파싱(Parsing)되어 DOM, CSSOM 트리로 변환되고 렌더 트리로 결합된다. 이렇게 생성된 렌더 트리를 기반으로 브라우저는 웹페이지를 표시한다.

 

자바스크립트는 렌더링 엔진이 아닌 자바스크립트 엔진이 처리한다. HTML 파서는 script 태그를 만나면 자바스크립트 코드를 실행하기 위해 DOM 생성 프로세스를 중지하고 자바스크립트 엔진으로 제어 권한을 넘긴다. 제어 권한을 넘겨 받은 자바스크립트 엔진은 script 태그 내의 자바스크립트 코드 또는 script 태그의 src 어트리뷰트에 정의된 자바스크립트 파일을 로드하고 파싱하여 실행한다. 자바스크립트의 실행이 완료되면 다시 HTML 파서로 제어 권한을 넘겨서 브라우저가 중지했던 시점부터 DOM 생성을 재개한다.

 

 

참고: poiemaweb.com/js-browser

medium.com/@monica1109/how-does-web-browsers-work-c95ad628a509

3. client side rendering vs server side rendering ?

Client Side Rendering

클라이언트 사이드 렌더링은 SPA로, 클라이언트 사이드에서 HTML을 반환한 후에, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것
점점 더 복잡해지는 웹페이지를 구현하기 위해서 전통적인 방식의 SSR보다는 CSR로 웹을 구현하는 경우가 많아짐

• 동작과정 : HTML 다운로드-> JS 다운로드 -> JS 실행 -> DATA 서버로부터 받기 -> Content 확인가능

1) CSR의 장점

• 클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기때문에 SSR 보다 조금 더 빠른 인터랙션이 가능
• page 전체를 요청하지 않고 페이지에 필요한 부분만 변경하게 하기 때문에, 모바일 네트워크에서도 빠른 속도로 렌더링이 가능
• lazy loading을 지원해줌
  lazy loading이란 ? 페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 기술
  (Ex. 스크롤 내려야만 해당 이미지 보이게 하는 것)
• 서버사이드 렌더링이 따로 필요하지 않기때문에 일관성있는 코드를 작성할 수 있음

2) CSR의 단점

• Googlebot과 Searchconsole에 검색 노출이 되지 않음 (브라우저가 없기때문에, html만 가져와서 검색에는 뜨지 않음)
• 페이지를 읽고, 자바스크립트를 읽은 후 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여지기 때문에 초기구동 속도가 느림

Server Side Rendering

서버에서 렌더링을 작업하는 렌더링 방식, 전통적인 웹 어플리케이션 렌더링 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 각각의 페이지에 대한 요청을 하며 서버에서 html, js 파일 등을 다 다운로드해서 화면에 렌더링하는 방식

1) SSR의 장점

• 사용자가 처음으로 컨텐츠를 볼 수 있는 시점을 앞당길 수 있음
• 검색엔진최적화(SEO) 적용이 용이

2) SSR의 단점

• 모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새페이지를 로딩하고 렌더해줌(새로고침)
• 전체를 로딩하다보니 CSR보다 느리고, bandwitdh를 많이 쓰고, 사용자 경험 좋지 않음
  (사용자가 처음으로 컨텐츠를 볼 수는 있으나, 화면단에는 html요소들이 나오나 js파일이 다 다운로드 되지않아서 버튼이 클릭되지않는 등의 현상이 있을 수 있음)

4. bundling에 이 무엇이며 왜 필요한가요? 본인이 경험한 bundling 을 소개해 주세요, 무슨 툴을 쓰셨나요?

A bundle is a directory in the file system that groups related resources together in one place. Applications, frameworks, and plug-ins are all examples of bundles. Programs can also use document bundles instead of flat files to save complex content.

Many bundles are also packages, that is, they are presented to the user as opaque files rather than as directories. This opaqueness has advantages for both users and developers. For users, it simplifies the user’s interaction with applications and other bundles and makes it harder to delete critical resources accidentally. For developers, it simplifies the software distribution process.

 

Bundling like it’s a seamless and native thing

There is no native way to ‘build’ a JavaScript application. This isn’t like C++ or Java where you need to compile the program to make it work. The point of JavaScript is that it runs on the fly in the browser — efficiency is not part of the original equation.

‘Building’ a JavaScript application is more to do with minifying the current application and creating a streamlined output. It’s not concerned about human readability or comprehension, shortening your values and variables in places that it can. Bundling tools like Webpack are merely repackaging up ECMAScript in a form that is much more efficient in terms of final produced file. Your trusty console is often the portal into performing this fantastic act of calculated magic.

A bundle is the output of a process that merges everything into a few (if not single) file in the most optimized manner.

 

번들링 장점

• 이전에 각 파일들마다 서버에 요청을 하여 자원을 얻어와야했던 반면, 같은 타입(html, css, js 등)의 파일을 묶어서 요청/응답을 받기 때문에 네트웍 코스트가 줄게 된다.
• Webpack 4버전 이상부터는 [ development ], [ production ] 이 두가지의 mode 지원을 하면서, 특히 production 모드로 번들링을 진행할 경우, 코드 난독화, 압축, 최적화(Tree Shaking) 작업을 지원하기도 한다. 한마디로 상용화 된 프로그램을 사용자가 느끼기에 더욱 쾌적한 환경 및 보안까지 신경쓰면서 노출시킬 수 있다는 점이다.
• Webpack의 주요 구성 요소 중 하나인 로더(Loder)가 일부 브라우저에서 지원이 되지 않는 ES6 형식의 자바스크립트 파일을 ES5로 변환하여 사용가능하게 한다. 웹 개발을 진행할 때 크롬과 같은 대중적인 브라우저만 고려하는 것이 아닌, 다른 모든 브라우저에 대해서도 커버가 가능하다는 뜻이다.

 

Webpack

Webpack website for script bunding and further information

Webpack is a modern static file bundling tool. In case of JavaScript file bundling, it helps to eliminate the implicit dependency on sorted <script> tags in our markup. Instead of including many separate scripts, we include single or few bundles using the same <script> tag.

To do so, we should first create those bundles. And to create bundles, we need to configure Webpack. Of course, Webpack should be installed on the machine — for example by command npm install webpack --save-dev.

 

자세한설명: betterprogramming.pub/modern-approach-of-javascript-bundling-with-webpack-3b7b3e5f4e7

humanwater.tistory.com/2

5. 프론트엔드 입장에서 신경써야 할 보안은 무엇들이 있을까요?

10가지: yohanpro.com/posts/front-end-security

13가지: ichi.pro/ko/peuleonteu-endeu-aeb-eul-wihan-13-gaji-boan-tib-74318368569490

6. CSRF가 무엇이며 어떻게 하면 막을 수 있나요?

로그인된 사용자가 자신의 의미와 무관하게 공격자가 의도한 행위(수정, 삭제 등)를 하게 하는 해킹 기법

impact of CSRF attack

this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.

유저 은행 계좌의 이메일 주소를 변경하거나 비밀번호를 변경 또는 자금 이동(송금) 등을 야기할 수 있다. 즉, 유저 계좌에 대한 전적인 조작이 가능할 수도 있다.

 

CSRF 막는법

구분	취약점	대응방안
CSRF	쿠키 가로 채기	– 입력값 검증, 검출 시 Reject
	세션 변조 사용	– Query String 검사, GET금지
	부정 클릭 사용	– Unique Token 사용
	DRDoS 공격참여	– DoS 공격 관련 취약점 제거

6 actions you can take to prevent a CSRF attack

• Make sure your anti-virus software is up to date. Many malicious scripts can be blocked and quarantined by this software.

• Do not open any emails, browse to other sites or perform any other social network communication while authenticated to your banking site or any site that performs financial transactions. This will prevent any malicious scripts from being executed while being authenticated to a financial site.

• Whenever you finish a banking or financial transaction on a site always log off immediately. Don’t just minimize or close the browser. If you do, it will make you vulnerable to an attack. 

• Never save your login or password for a banking or financial institution site within your browser. Malicious code in CSRF attacks is usually written to take advantage of this information that is within your browser

• Disable scripting in your browser. Firefox has a plugin that can prevent scripts from running.

• Run all your financial or banking transactions in one browser and all your other browsing within another. This way an attacker cannot make your general web browser do anything malicious to your banking or financial transaction browser.

자세한설명: nomadkim880901.tistory.com/356

www.networkworld.com/article/3190444/how-to-protect-against-cross-site-request-forgery-attacks.html

 

7. XSS가 무엇이며 어떻게 하면 막을 수 있나요?

웹사이트에 악의적 스크립트 삽입하여 쿠키 및 기타 개인정보를 특정 사이트로 유출하는 해킹 기법

Cross-site scripting (XSS) is a security exploit which allows an attacker to inject into a website malicious client-side code. This code is executed by the victims and lets the attackers bypass access controls and impersonate users.

 

• XSS is a web-based attack performed on vulnerable web applications.
• In XSS attacks, the victim is the user and not the application.
• In XSS attacks, malicious content is delivered to users using JavaScript.

 

These attacks succeed if the Web app does not employ enough validation or encoding. The user's browser cannot detect the malicious script is untrustworthy, and so gives it access to any cookies, session tokens, or other sensitive site-specific information, or lets the malicious script rewrite the HTML content.

유저의 브라우저는 악의적인 스크립트를 탐지해낼 수 없기 때문에 쿠키, 토큰, 민감한 사이트 특정 정보에 접근을 허용하거나 브라우저 HTML content에 재작성을 허용한다.

 

XSS 막는법

구분	취약점	대응방안
XSS	쿠키 정보 추출	– 중요정보 Cookie 저장 방지
	특수문자 이용	– 입력값 검증, 특수문자 필터링
	HTML 태그	– ‘<’, ‘>’ 사용금지 ‘&lt’등 사용
	링크 노출	– 링크 복사하여 직접 접근

 

8. JSONP를 알고 있나요? 왜 필요하며 특징은 무엇인가요

JSONP란?

• JSONP란 CORS가 활성화 되기 이전의 데이터 요청 방법으로, 다른 도메인으로부터 데이터를 가져오기 위해 사용하는 방법입니다.
• 자바스크립트는 서로 다른 도메인에 대한 요청을 보안상 제한하는데, 이 정책은 Same-Origin Policy, SOP라고 합니다.
• SOP 정책으로 인해 생기는 이슈를 Cross-domain issue라고 하는데 JSONP는 이 이슈를 우회해서 데이터 공유를 가능하게 하였습니다.

JSONP 동작방식

• JSONP는 HTML 문서의 script 태그로 다른 도메인을 요청 할 시 SOP 정책이 적용되지 않는 방식을 이용하여 동작합니다.
• script 태그는 src 속성 값을 호출한 결과를 javascript로 불러와서 즉시 실행시키는 기능입니다.
• 바로 예를 들어 보겠습니다.
  * http://server.example.com/post/1 을 요청할 시 다음과 같은 json 데이터를 반환한다고 가정합니다. 

  { 
  "title" :  "JSONP란?" , 
  "author" :  "yesdoing", 
  "content" :  "쏼라쏼라" 
  }

  * 도메인에서 `script` 태그로 데이터를 호출해서 사용하려고하면 오류가 발생합니다.

<script src="http://server.example.com/post/1"> 
</script>	 

	* 오류가 발생하는 이유는 `<script>` 파일을 다운로드하고 그 내용을 해석할 때 JSON 객체로 해석하지 않고 {}을 블록으로

• JSON 데이터가 객체 리터럴로 해석된다 하더라도 브라우저에서 실행중인 Javascript에서는 변수에 값을 저장하지 않았으므로 접근을 할 수 없습니다.
• 이 JSON데이터를 사용하기 위해서는 src 속성의 값 뒤에 ?callback=콜백함수명을 붙여서 요청을 합니다. 그럼 이 요청의 결과로 콜백함수의 인자에 객체를 전달하여 실행시켜 줍니다.
• 즉, JSONP를 사용하기 위해서는 서버에서 데이터를 반환할때 콜백함수를 감싸주는 처리가 필요합니다. 

callbackFunction( 
{ 
"title" : "JSONP란?" , 
"author" : "yesdoing", 
"content" : "쏼라쏼라" } 
); ```

9. 리액트란 무엇인가요? 다른 JS 프레임워크와 어떤 특징, 차별점이 있나요?

UI 자바스크립트 라이브러리로써 싱글 페이지 애플리케이션의 UI(User Interface)를 생성하는데 집중한 라이브러리입니다.

리액트는 자바스크립트에 HTML을 포함하는 JSX(JavaScript XML)이라는 간단한 문법과 단방향 데이터 바인딩(One-way Data Binding)을 사용하고 있습니다. 그리고 가상 돔(Virtual DOM)이라는 개념을 사용하여 웹 애플리케이션의 퍼포먼스를 최적화한 라이브러리입니다.

 

특징

• Component
• JSX (JavaScript XML)
• Virtual DOM
• 단방향 데이터 바인딩

장점

#Component

컴포넌트란 UI를 구성하는 개별적인 view 단위이다. 전체의 앱은 각 컴포넌트를 조립해서 만들어진다. 모듈화를 통해 유지, 보수가 용이하다는 점이 있다. 본인에게는 컴포넌트가 모듈화의 가이드라인을 제시해주는 것처럼 느껴진다.

 

#JSX

React에서 새로 도입된 자바스크립트 문법이고 React에서만 사용된다. JSX 문법을 사용하지 않고도 React 개발이 가능하며, 또한 브라우저에게 이해시키기 위해서는 초기 Webpack 설정이 필수(create-react-app을 사용하면 자동으로 추가되지만)이다. 그럼에도 JSX를 사용하는 중요한 이유중 하나는 코드의 직관성이다.

 

HTML과 JavaScript를 분리하여 개발하는 것이 기존의 개발 방법이었다. 그래서 한쪽의 코드만 봤을 때 이 코드가 정확히 어떤 동작을 하는 것인지 쉽게 알 수 없었다. 이에 유저에게 보여주고 싶은 view에 개발자가 직관적으로 도달할 수 있도록, 마치 HTML과 JavaScript가 합쳐진 것처럼 보이는 JSX가 도입되었다.

 

#Virtual DOM

DOM은 브라우저가 화면을 그리기위한 정보를 담고있는 문서 객체이다. JQuery처럼 실제 DOM을 변경할 경우, 변경할 부분이 일부분이더라도 DOM 전체를 다시 렌더링해야하고, 이는 성능 저하로 직결된다는 단점이 있다.

 

React는 렌더링 시 Virtual DOM, 즉 가상 DOM을 먼저 만든다. 그 후 실제 DOM과 비교를 하여 변경이 있는 부분(하위 컴포넌트)만 대체를 하기 때문에 리소스 낭비를 줄일 수 있다. 라이브러리를 통해 React에서도 JQuery를 사용할 수 있지만 이는 추천되지 않는 방법이다.

 

#단반향 데이터 바인딩

React 내에서의 데이터의 흐름은 부모(Parent)에서 자식(Child)으로 단방향적이다. 그렇기 때문에 디버깅이 용이하며, 다른 라이브러리에 비해 안전성이 높다.

다만, 전역에서 접근해야하는 데이터가 존재할 경우(로그인 여부 등...)가 있고, 이는 Redux를 통해 관리를 하는 방법도 존재한다.

 

#활발한 커뮤니티

모든 기술이 그렇듯 커뮤니티가 얼마나 크고 활발한지가 해당 기술을 선택하는 척도 중 하나다. 여러 자바스크립트 라이브러리와 프레임워크가 있겠지만 그 중에서도 React가 제일 높은 시장 점유율과 선호도를 갖고 있다. 그렇기 때문에 다양한 라이브러리 사용이 가능해진다.

 

#React Native

리액트 네이티브를 활용한 앱 개발이 가능하다. 앱의 운영 환경(Android, iOS) 과는 상관없이 작동하는 앱을 만들 수 있다. 본인은 아직 시도해보지 않았지만 몇가지 태그와 속성을 제외하면 React JS와 동일하다고 알고있다.

 

참고: dev-yakuza.posstree.com/ko/react/create-react-app/react/

 

10. react state and props에 대해 설명해 보세요

Common ground

Before separating props and state, let's also identify where they overlap.

• Both props and state are plain JS objects
• Both props and state changes trigger a render update
• Both props and state are deterministic. If your Component generates different outputs for the same combination of props and state then you're doing something wrong.

Does this go inside props or state?

tl;dr: If a Component needs to alter one of its attributes at some point in time, that attribute should be part of its state, otherwise it should just be a prop for that Component.

props

props (short for properties) are a Component's configuration, its options if you may. They are received from above and immutable as far as the Component receiving them is concerned.

A Component cannot change its props, but it is responsible for putting together the props of its child Components.

state

The state starts with a default value when a Component mounts and then suffers from mutations in time (mostly generated from user events). It's a serializable* representation of one point in time—a snapshot.

A Component manages its own state internally, but—besides setting an initial state—has no business fiddling with the state of its children. You could say the state is private.

* We didn't say props are also serializable because it's pretty common to pass down callback functions through props.

 

Changing props and state

Can get initial value from parent Component?	Yes	Yes
Can be changed by parent Component?	Yes	No
Can set default values inside Component?*	Yes	Yes
Can change inside Component?	No	Yes
Can set initial value for child Components?	Yes	Yes
Can change in child Components?	Yes	No

props state

* Note that both props and state initial values received from parents override default values defined inside a Component.

 

Should this Component have state?

state is optional. Since state increases complexity and reduces predictability, a Component without state is preferable. Even though you clearly can't do without state in an interactive app, you should avoid having too many Stateful Components.

Component types

• Stateless Component — Only props, no state. There's not much going on besides the render() function and all their logic revolves around the props they receive. This makes them very easy to follow (and test for that matter). We sometimes call these dumb-as-f*ck Components (which turns out to be the only way to misuse the F-word in the English language).
• Stateful Component — Both props and state. We also call these state managers. They are in charge of client-server communication (XHR, web sockets, etc.), processing data and responding to user events. These sort of logistics should be encapsulated in a moderate number of Stateful Components, while all visualization and formatting logic should move downstream into as many Stateless Components as possible.

 

참고: github.com/uberVU/react-guide/blob/master/props-vs-state.md

11. react immutable 에 대해 설명해 보세요

리액트에서는 시간적 비용이 어느정도 들더라도, 객체를 불변객체로 만들어 프로퍼티의 직접적인 변경을 방지하고, 객체의 변경이 필요한 경우에는 새로운 객체로 복사하여 그 값을 다루도록 한다.

특히 리액트에서는 상태(객체)를 참조 형태로 전달하고 전달받기 때문에, 참조를 통해 전달된 객체들이 예기치 않게 변경되었을때, 프로그램 전반적으로 큰 오류를 야기하는 가능성이 있다. 변경이 이루어진 해당 객체를 구독하고있는 모든 컴포넌트와 로직에 영향을 끼친다. 

 

react는 기본적으로 부모 컴포넌트가 리렌더링을 하면 자식 컴포넌트도 리렌더링하게 됩니다.즉, 얕은 비교를 통해 새로운 값인지 아닌지를 판단한 후 새로운 값인 경우 리렌더링을 하게 됩니다
여기서 얕은 비교란 간단히 말하자면 객체, 배열, 함수와 같은 참조 타입들을 실제 내부 값까지 비교하지 않고 동일 참조인지(동일한 메모리 값을 사용하는지)를 비교하는 것을 뜻합니다

• state가 얕은 비교를 통해 컴포넌트가 리렌더링 된다는 말은 굉장한 의미가 있습니다.

1. 우리가 컴포넌트를 리렌더링 해야하는 상황이 있다고 가정하고, 타입이 배열인 state를 바꿉니다.
2. 이때, state.push(1)을 통해 state 배열에 직접 접근하여 요소를 추가합니다.
3. 우리는 push 전과 다른 값이라고 생각하지만, 리엑트는 state라는 값은 새로운 참조값이 아니기 때문에 이전과 같은 값이라고 인식하고 리렌더링 하지 않습니다.

• 즉, 위 이유로 우리가 state를 바꾸고 돔을 다시 만들려면, 새로운 객체 or 배열을 만들어 새로운 참조값을 만들고, react에게 이 값은 이전과 다른 참조값임을 알려야하는 것입니다.

 

참고: kyounghwan01.github.io/blog/React/immer-js/#%E1%84%87%E1%85%AE%E1%86%AF%E1%84%87%E1%85%A7%E1%86%AB%E1%84%89%E1%85%A5%E1%86%BC-%E1%84%8C%E1%85%B5%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A7%E1%86%AB%E1%84%89%E1%85%A5-state-%E1%84%87%E1%85%A1%E1%84%81%E1%85%AE%E1%84%80%E1%85%B5

불변성에 대한 자세한 설명: evan-moon.github.io/2020/01/05/what-is-immutable/

12. 리액트에 있는 라이프 사이클들을 이야기해보고, 각 라이프 사이클은 어떤 용도로 유익할지 설명해 보세요

참고: velopert.com/1130

13. react router 와 같은 client side routing에 대해 설명해 주세요

Client-side Routing

Client-side routing is handled solely by JavaScript on the page. Whenever a user clicks on a link, the URL bar changes and a different view is rendered on the page. This view could be anything—JSX or HTML. Single-page applications give a smooth sense of navigation as they don't refresh the whole page when a route is performed. Even when a request is made to the server to fetch data, it only seems as if static HTML pages are rendered on the frontend. Thus, single-page applications are direct beneficiaries of client-side routing, and this is one major reason for their growing popularity and delivery of great user experience.

Let's look at the pros and cons of client-side routing.

Pros

 

• Routing between components is fast as the amount of data that renders is less. The rest of the data is rendered by the DOM, and even when there's tons of HTML and CSS to render, the DOM handles that part in the blink of an eye. Using lazy loading, any delay in rendering HTML is compensated for.

 

 

• For better user experience, animations and transitions can be easily implemented when switching between different components.

 

 

• It gives a real sense of a single-page application in action. No separate pages are rendered, and the current page doesn't refresh to load a new view.

 

Cons

 

• The initial loading time is considerably large as all the routes, components, and HTML have to be loaded at once when the application first mounts . The whole website or web app needs to be loaded on the first request.

 

 

• There is unnecessary data download time for unusable views that cannot be anticipated on the first render of the application.

 

 

• It generally requires an external library, which means more code and more dependency on external packages, unlike routing on the server-side.

 

 

• Client-side routing and rendering convert JavaScript to HTML, making search engine crawling less optimized.

 

참고: www.pluralsight.com/guides/pros-and-cons-of-client-side-routing-with-react

14. What can you tell me about JSX?

Javascript + XML을 합쳐서 탄생한 기존 자바스크립트의 확장 문법입니다.

개발자가 자바스크립트 내부에 마크업 코드를 작성해 줄 수 있게 해줍니다.
단순히 XML만 아니라 변수나 프로퍼티의 바인딩 기능도 제공합니다

const element = <h1>Hello, world!</h1>;
 
ReactDOM.render(
  element,
  document.getElementById('root')
);

장점

1. 가독성이 좋다  - 자바스크립트에 비해, JSX를 사용하면 보기 쉽고, 작성하기 쉽다.

2. 오류 검사가 가능하다 - babel-loader에 의해 오류를 감지할 수 있다.

3. 거부감없이, 쉽게 작성할 수 있다 - HTML과 유사하기 때문에 쉽게 작성이 가능하다.

출처: https://codingmania.tistory.com/323 [괴발개발 개발새발 하는 개발자의 개발 블로그]
출처: https://blog.sonim1.com/175 [Kendrick's Blog]

 

15. flux vs mvc ?

MVC:

MVC is an architecture first introduced by Trygve Reenskaug into Smalltalk-76. Since then it has been adopted by many developers group and companies both in server and client side development.

MVC Architecture

In MVC design good as separation of each layer, as view, model, controller, Though many of them has modified the actual principal, some came up with MVVM and MV* kind of architectures, but the focus was on MVC and that’s why it’s one of the most successful architectures.

• Model: manages the behavior and data of the application domain
• View: represents the display of the model in the UI
• Controller: takes user input, manipulates the model and causes the view to update

Good Point in MVC:

Great separation of code easy to maintain in JS frameworks like ember ,well implementation of MVC

1. separating presentation from model should be improving testability.
2. separating view from controller most useful in web interfaces.

Bad Point in MVC:

In server Side, MVC is good,but in Client side most of the JS frameworks provide data binding support which let the view can talk with model directly, It shoudn’t be,Many times it become hard to debug something as there are scope for a property being changed by many ways.

MVC Debugging problem.

Facebook developers were facing problem scaling their MVC application and as a result of that the world got a new architecture flux. In a conference of FB developers, they showed how following MVC messed things up using the above diagram.

Facebook faces the problem while developing chat system, view1 manipulates model1 and model1 updates the view2 like their system has circular dependency thats why they came up with solution flux.

 

Flux:

Facebook definition for Flux:

Flux is the application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code.

• Actions are simple objects with a type property and some data. For example, an action could be {“type”: “IncreaseCount”, “local_data”: {“delta”: 1}}
• Stores contain the application’s state and logic. The best abstraction is to think of stores as managing a particular domain of the application. They aren’t the same as models in MVC since models usually try to model single objects, while stores in Flux can store anything
• The Dispatcher acts as a central hub. The dispatcher processes actions (for example, user interactions) and invokes callbacks that the stores have registered with it. The dispatcher isn’t the same as controllers in the MVC pattern — usually the dispatcher does not have much logic inside it and you can reuse the same dispatcher across projects
• Views are controller-views, also very common in most GUI MVC patterns. They listen for changes from the stores and re-render themselves appropriately. Views can also add new actions to the dispatcher, for example, on user interactions. The views are usually coded in React, but it’s not necessary to use React with Flux

16. redux에 대해 설명해 보세요

상태 관리 라이브러리 목적?

React 특성인 불필요한 렌더링을 보완하기 위함.

 

React 렌더링 조건이라 하면,

1. State 가 변경된 경우

2. State 변경으로 인해 Props 가 변경된 경우

3. 부모 컴포넌트가 렌더링된 경우

 

즉, state 값 변경으로 인해 re-rendering 이 발생하는데

이 때 re-rendering 이 필요없는 컴포넌트(state 값에 영향을 받지 않는) 또한 렌더링되는 성능저하를 초래한다.

프로젝트의 규모가 커질수록 data flow 가 복잡해질 수 있고 버그나 오류로 인해 트래킹이 불가할 수 있다.

 

어떻게?

컴포넌트와 상태를 분리 Store 라는 오직 하나의 상태관리 공간을 만들어 상태 변화가 생겼을 때 해당 상태를 사용하는 컴포넌트만 렌더링 시킨다.

Redux 의 장점

1. 상태를 예측 가능하게 만들어준다.

2. 유지보수가 용이하다.

3. 디버깅에 유리하다. action과 state log를 기록하면 추적이 가능. => redux dev tool 로 확인할 수 있다.

4. 테스트를 붙이기 쉽다.

순수함수를 사용하기 때문에 테스트를 붙이기 쉽다.

5. React 는 UI 만 담당하는 것과 같아지기 때문에 Redux를 통한 데이터 관리가 쉬워진다.

모든 데이터는 Redux 로 관리.

 

출처: nomadkim880901.tistory.com/395

17. lazy loading이란?

Lazy loading is a strategy to identify resources as non-blocking (non-critical) and load these only when needed. It's a way to shorten the length of the critical rendering path, which translates into reduced page load times.

Lazy loading can occur on different moments in the application, but it typically happens on some user interactions such as scrolling and navigation.

 

lazy loading은 페이지 내에서 실제로 필요로 할 때까지 리소스의 로딩을 미루는 것입니다. 페이지를 로드하자마자 리소스를 로딩하는 일반적인 방식 대신, 실제로 사용자 화면에 보여질 필요가 있을 때까지 이러한 로딩을 지연하는 것입니다.

laze loading을 다루는 방식은 페이지 내의 거의 모든 리소스에 적용할 수 있습니다. 예를 들어, SPA(Single Page Application) 내에서 JS 파일이 나중에까지 필요하지 않으면 초기에 로드해서 가져오지 않는 것이 가장 좋습니다. 이 처럼 이미지도 바로 보여질 필요가 없다가, 실제로 보여질 필요가 있을 때 로딩을 하는 것입니다.

 

왜 lazy loading을 사용해야 하는가

Lazy Loading은 페이지 내에서 바로 필요하지 않은 이미지들을 로딩 시점을 뒤로 미루는 것입니다. 페이지 로드 시점에 유저에게 보여지지 않는 이미지는 스크롤 등으로 실제로 이미지가 보여지는 시점이 올 때 로딩됩니다. 만약 사용자가 스크롤하는 행위가 없으면, 사용자에게 보여지지 않은 이미지는 절대 로딩되지 않습니다.

이것은 2가지의 장점을 가지고 있습니다.

 

1. 성능 향상

이것은 웹 사이트의 로딩 시간, 성능 관리 면에서 가장 중요한 요소 중 하나입니다.

lazy loading을 이용하면, 페이지 초기 로딩 시 필요로 한 이미지의 수를 줄일 수 있습니다. 리소스 요청을 줄이는 것은 다운로드 bytes를 줄이는 것이며, 이는 유저가 사용할 수 있는 제한된 네트워크 대역폭의 경쟁을 줄이는 것을 의미합니다. 이것은 디바이스가 다른 리소스들을 더 빠르게 처리해서 다운로드하도록 확보하는 것입니다. 그러므로, lazy loading을 쓰지 않는 것에 비해서 페이지를 훨씬 빨리 유저가 이용하게 되는 것입니다.

 

2. 비용 감소

두 번째 장점은 통신 비용 관점에 있습니다. 이미지 전달 또는 다른 전달할 무언가는 주로 전송 바이트 수에 기반하여 청구됩니다.

lazy loading에 대해 앞서 언급했듯이, 이미지가 보여지지 않으명 절대 로딩하지 않으므로, 페이지 내에서 전달할 총 바이트 용량을 줄일 수 있습니다. 특히나 페이지를 이탈하거나 페이지의 제일 상단에만 서비스를 이용하는 유저에게 효과적입니다. 이처럼 네트워크로부터 전송될 바이트의 감소는 전송 비용을 줄입니다. 이 부분은 lazy loading에 대해 알아보면서 더욱 자세하게 알게 될 것입니다.

 

참고: helloinyong.tistory.com/297

 

18. SPA는 기존 웹사이트와 무엇이 다른가요?

SPA(Single Page Application)은 Client Side Rendering (혹은 Client Side Navigation) 방식으로 어플리케이션 생명 주기 중에서 단 한 번만 리소스(HTML, CSS, JavaScript) 를 로딩하고, 그 후에는 데이터를 받아올 때만 서버와 통신합니다. 정리하자면 첫 요청시 딱 한 페이지만 불러오고 페이지 이동시 기존 페이지의 내부를 수정해서 보여주는 방식입니다.

이를 사용자(클라이언트) 관점에서 다시 말하자면 최초 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로 부터 받아서 화면을 갱신하는 것 입니다. 필요한 부분만 갱신하기 때문에 네이티브 앱에 가까운 자연스러운 페이지 이동과 사용자 경험(UX)을 제공할 수 있습니다.

 

👍 SPA 장점

1. 자연스러운 사용자 경험(UX)
2. 필요한 리소스만 부분적으로 로딩(성능)
3. 서버의 탬플릿 연산을 클라이언트로 분산(성능)
4. 컴포넌트별 개발 용이(생산성)
5. 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능(생산성)

👎 SPA 단점

1. JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도 느림(webpack 의 code splitting으로 해결)
2. 검색엔진최적화(SEO)가 어려움 (SSR 로 해결)
3. 보안 이슈 (프론트엔드에 비즈니스 로직 최소화)

중복된 리소스 요청없이 정확히 필요한 요청만 하기 때문에 대부분의 경우 퍼포먼스 상 이득이 있고, 사용자에서 네이티브 앱과 비슷한 수준의 향상된 사용자 경험(UX)을 제공할 수 있어서 최근 spa 가 대세가 되고 있습니다.

 

참고: medium.com/aha-official/%EC%95%84%ED%95%98-%ED%94%84%EB%A1%A0%ED%8A%B8-%EA%B0%9C%EB%B0%9C%EA%B8%B0-1-spa%EC%99%80-ssr%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EA%B7%B8%EB%A6%AC%EA%B3%A0-nuxt-js-cafdc3ac2053

19. AJAX 기술에 대해 설명해 보세요

Asynchronous JavaScript + XML(AJAX)

비동기 + DOM + fetch(XMLHTTPRequest)

 

서버 응답에 따라 "동적"으로 페이지의 구성요소를 변경(ex 검색어 자동완성 추천 기능)하는 API 의 역할을 한다고 볼 수 있다.

 

• HTML, CSS, JavaScript, DOM 조작과 XMLHttpRequest object를 활용한 프로그래밍 방식이다.
• AJAX는 전체 페이지가 다시 로드되지 않고 일부분만 업데이트하는 좀 더 복잡한 웹페이지를 만들 수 있게 해준다.
• 서버에 필요한 정보를 요청하고 JS로 DOM만 바꿔 렌더한다.
• AJAX를 사용하면 웹페이지 일부가 리로드 되는 동안에도 코드가 계속 실행되어 비동기식으로 작업할 수 있다.

*XML: The Extensible Markup Language (XML) is a W3C-recommended general-purpose markup language for creating special-purpose markup languages. Its primary purpose is to facilitate the sharing of data across different systems, particularly systems connected via the Internet.

 

참고: nomadkim880901.tistory.com/354

20. script tag의 위치와 위치에 따라 고려해야 하는 점은 무엇인가요

velog.io/@takeknowledge/script-%ED%83%9C%EA%B7%B8%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%9C%84%EC%B9%98%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C%EC%9A%94

21. 이벤트 버블링이란 무엇인가요? 어떻게 막을 수 있나요?

한 요소에 이벤트가 발생하면, 이 요소에 할당된 핸들러가 동작하고, 이어서 부모 요소의 핸들러가 동작합니다. 가장 최상단의 조상 요소를 만날 때까지 이 과정이 반복되면서 요소 각각에 할당된 핸들러가 동작합니다.

 

3개의 요소가 FORM > DIV > P 형태로 중첩된 구조를 살펴봅시다. 요소 각각에 핸들러가 할당되어 있습니다.

<style>
  body * {
    margin: 10px;
    border: 1px solid blue;
  }
</style>

<form onclick="alert('form')">FORM
  <div onclick="alert('div')">DIV
    <p onclick="alert('p')">P</p>
  </div>
</form>

 

가장 안쪽의 <p>를 클릭하면 순서대로 다음과 같은 일이 벌어집니다.

1. <p>에 할당된 onclick 핸들러가 동작합니다.
2. 바깥의 <div>에 할당된 핸들러가 동작합니다.
3. 그 바깥의 <form>에 할당된 핸들러가 동작합니다.
4. document 객체를 만날 때까지, 각 요소에 할당된 onclick 핸들러가 동작합니다.

이런 흐름을 '이벤트 버블링’이라고 부릅니다. 이벤트가 제일 깊은 곳에 있는 요소에서 시작해 부모 요소를 거슬러 올라가며 발생하는 모양이 마치 물속 거품(bubble)과 닮았기 때문입니다.

 

버블링 막기

 

1. 부모에게 이벤트 전파되는 것을 막는 stopPropagation()

2. 같은 DOM에 걸린 다른 이벤트에 전파되는 것을 막는 stopImmediatePropagation()

3. 현재 이벤트의 기본 동작을 중단하는 preventDefault()

4. stopPropagation() 과 preventDefault() 모두 수행한 것과 같은 return false

 

참고: ko.javascript.info/bubbling-and-capturing

 

22. CSS보다 SCSS/SASS가 가지고 있는 장점은?

 

SCSS와 SASS는 CSS를 편리하게 이용할 수 있도록 도와주며 추가 기능도 있는 확장판 ( CSS를 확장하는 스크립팅언어 ) 정도

<ul class='list'>
  <li>1</li>
  <li>2</li>
  <li>3</li>
</div>

//CSS 
.list {
  width: 100px;
  float: left;
  }
li {
  color: red;
  background: url("./image.jpg");
  }
li:last-child {
  margin-right: -10px;
  }
//SCSS
.list {
  width: 100px;
  float: left;
  li {
    color: red;
    background: url("./image.jpg");
    &:last-child {
      margin-right: -10px;
    }
  }
}
//SASS
.list
  width: 100px
  float: left
  li
    color: red
    background: url("./image.jpg")
    &:last-child
      margin-right: -10px

1) 왜 쓰냐?

CSS가 복잡한 언어는 아니지만 작업이 크고 고도화 될수록 불편함이 생긴다.

이에 SCSS와 Sass는 불필요한 선택자(Selector)의 과용과 연산 기능의 한계, 구문(Statement)의 부재 등 프로젝트가 커지면서 복잡해지는 CSS 작업을 쉽게 해주며 가독성과 재사용성을 높여주어 유지보수가 쉬워지게 도와준다.

그리고 CSS의 태생적 한계를 보완하기 위해 Sass는 다음과 같은 추가 기능과 유용한 도구들을 제공한다.

• 변수의 사용
• 조건문과 반복문
• Import
• Nesting
• Mixin
• Extend/Inheritance
  CSS와 비교하여 Sass는 아래와 같은 장점이 있다.

CSS보다 심플한 표기법으로 CSS를 구조화하여 표현할 수 있다.
스킬 레벨이 다른 팀원들과의 작업 시 발생할 수 있는 구문의 수준 차이를 평준화할 수 있다.
CSS에는 존재하지 않는 Mixin 등의 강력한 기능을 활용하여 CSS 유지보수 편의성을 큰 폭으로 향상시킬 수 있다.

 

2) Sass와 SCSS 차이가 뭐냐?

SCSS는 Sassy CSS(멋진 CSS)의 줄임말이고 SASS는 Syntactically Awesome Style Sheets (문법적으로 짱 멋진 스타일시트)의 줄임말이다. 둘 다 멋진 스타일 시트란 말인데 어떤 차이가 있을까?

우선 코드에 대한 대략적인 차이는 위의 코드에서 눈으로 확인 할 수 있다.
문법을 포함한 여러 차이점이 있지만 간단히 요약하자면 SASS보다 SCSS가 뒤에 나왔고 여러가지 문법의 차이가 있지만 SCSS가 더 넓은 범용성과 CSS의 호환성 등의 장점으로 SCSS를 사용하기를 권장하고 있다.(공식문법도 SCSS를 기준으로 나와있다고 함) 따라서 SASS는 통상적으로 SCSS라고 부르기도 하는 것 같다.
둘의 차이에 대한 상세한 내용은 다음 링크에서 확인이 가능하다.
https://designmeme.github.io/ko/blog/write-sass-with-scss/

 

3) 추가

그리고 Sass(SCSS)를 CSS pre-processor(전 처리기)라고도 하는데 이는 Sass자체로 브라우저에 적용하는 것이 아니라 CSS를 확장해서 쉽고 편리하게 쓰기 위해 쓰는 스크립팅 언어이기 때문에
따라서 Sass로 작성한 코드는 컴파일을 해서 일반 CSS의 문법으로 바꾼 뒤 적용한다는 뜻이다.
아래 그림처럼.

출처: velog.io/@jch9537/CSS-SCSS-SASS

 

23. id와 class selctor는 어떻게 다르게 쓰이나요?

 

id 선택자와 class 선택자는 특정 요소를 대상으로 스타일을 적용하기 위한 것입니다. 예를 들어 id와 class를 사용하면 모든 <p>요소가 아닌 특정한 <p>요소에만 스타일을 적용할 수 있습니다.

 

id 선택자와 class 선택자의 차이는 문서 안의 '복수'의 요소에 스타일을 적용하는 것인가 아니면 '유일'한 요소에 스타일을 적용하는 것인가입니다. 결론적으로 말하면 id는 '유일'한 요소에 적용, class는 '복수'의 요소에 적용할 수 있습니다.

• id : '유일'한 요소에 스타일을 적용
• class : '복수'의 요소에 스타일을 적용

 

id와 class의 차이점을 다시 정리해보면..

• 하나의 id는 한 문서에서 한 번만 사용이 가능합니다.
• 하나의 class는 한 문서에서 여러 번 사용이 가능합니다.
• id의 속성이 class의 속성보다 우선 순위가 높습니다.
• 따라서 id의 속성은 해당 요소에 부여된 class 속성에 관계 없이 작동합니다.

출처: https://ohknow.tistory.com/35 [오늘의 잡지식 Oh~Know~]

 

24. css box model에 대해 말해보세요

www.zerocho.com/category/CSS/post/582ddf81d4416a001860e75d

25. css 에서 em, px, rem 의 차이점에 대해 이야기해 보세요

 

• 절대적이고 확실한 크기로 정하고 싶을 때
  • px(픽셀). px은 접근성에 불리하다. CSS를 통해 글꼴 크기가 고정되어 작은 글씨를 보기 힘든 사용자가 브라우저 기본 글꼴 크기를 더 크게 설정해도 무시되는 단점이 있다.  px은 모바일 기기와 같이 작은 화면이면서 고해상도인 경우에도 적합하지 않다. 기본적으로 고해상도에서는 1px이 모니터의 한 점보다 크게 업스케일(upscale)되기 때문에, 뚜렷하지 못한 형태로 출력될 수 있다. px은 화면 크기가 절대적인 경우에 (예를 들어 출력용) 유리하다.
    
• 보통의 경우
  • rem을 추천합니다. root의 글자 크기, 즉 브라우저의 기본 글자 크기가 1rem이며, 두배로 크게 하고 싶다면 2rem, 작게 하려면 0.8rem 등으로 조절해서 사용할 수 있습니다. 이는 사용자가 설정한 기본 글꼴 크기를 따르므로, 접근성에 유리합니다. (em은 부모 엘리먼트에 따라 상대적으로 크기가 변경되므로 계산이 어렵습니다. 이에 비해 rem은 root의 글자 크기에 따라서만 상대적으로 변합니다.) -> 최상위 태그 html에 정의된 사이즈를 기준으로 배수하겠다는 것을 의미합니다.
• 반응형 웹(responsive web)에서 기준점을 만들 때
  • 반응형 웹은 디바이스의 너비(width)에 따라 유동적인 레이아웃이 적용되는 웹사이트를 말합니다. 예를 들어, 데스크탑에서 볼 때, 스마트폰에서 세로 모드로 볼때, 가로 모드로 볼 때, 태블릿으로 볼 때가 각각 다를 수 있겠죠. 이 때에는 디바이스 크기 별로 CSS를 달리 적용해야 합니다. 이 때에, 디바이스 크기를 나누는 기준을 보통 px로 정합니다. 예를 들어 iPhone 12 Pro Max의 너비는 414px 입니다. 보통 450px 미만의 너비를 갖는 디바이스는 스마트폰 세로 모드로 생각해도 좋습니다. 크롬 브라우저에서는 자주 사용하는 디바이스의 너비(width)와 높이(height)별로 실제로 어떻게 보이는지 테스트해볼 수 있습니다.
• 화면 너비 및 높이에 따른 상대적인 크기가 중요한 경우
  • vw, vh를 사용하세요. 웹사이트의 보여지는 영역을 Viewport라고 하며, vw, vh는 viewport width 및 height를 의미합니다. 간혹 화면을 가득 채우며 딱 떨어지게 스크롤되는 사이트를 본 적이 있을겁니다. 이는 100vw, 100vh를 사용해 구현한 것입니다.

 

26. BMP, JPG, PNG 각각의 특징에 대해서 설명하라.

 

BMP: Windows 비트맵

 BMP 파일은 윈도우 배경 무늬에 적합합니다. Windows 비트맵은 1비트 흑백부터 24비트까지의 색 농도를 지원합니다.  
Windows 비트맵 파일 형식은 다른 Microsoft Windows 프로그램과 호환된다는 장점이 있지만, 파일 압축을 지원하지 않으며(그래서 파일 용량 큽니다.) 웹 페이지에 적합하지 않습니다. 사진 이미지의 경우 PNG 파일, JPEG 파일 또는 TIFF 파일을 이용하시는 것이 좋습니다. 

 

PNG: 이동식 네트워크 그래픽

  PNG는 플랫폼 독립적 형식으로 웹 브라우저에서도 지원되며 상위 수준의 무손실 압축, 알파 채널 투명성, 감마 조정, 인터레이스를 지원합니다. 인터넷 파일 형식으로서 PNG는 손실이 있는 JPEG 압축보다 압축률이 낮고, GIF와 같이 복수 이미지 파일이나 애니메이션 파일을 지원하지는 않습니다. 이미지 화질은 JPG보다 PNG가 좋습니다. 

 

JPEG: Joint Photographic Experts Group

  JPEG 그림은 광범위하게 지원되는 인터넷 표준으로 24비트 색으로 최고 수준의 압축을 제공하는 플랫폼 독립적 형식의 손실 압축 방식입니다. (압축 과정에서 손실 발생) 인터레이스(Progressive JPEG 파일의 경우)가 지원됩니다. 가변 압축을 통해 파일 크기를 줄일 수 있지만, JPEG 파일 크기를 줄이면 이미지 품질이 저하됩니다. (압축 비율은 최대 100:1까지 가능)

 사진처럼 사실적인 아트 파일의 경우 효과가 좋고 비슷한 색상을 잘 압축하지만, 밝기가 크게 대비되거나 색이 적고 굵은 경계선이나 큰 단색 영역이 있는 단순한 아트 파일의 경우에는 뛰어난 품질을 얻을 수 없습니다.

JPEG 형식은 10:1에서 20:1의 비율로 그림 품질을 거의 저하시키지 않고 파일을 안정적으로 압축합니다.
JPEG 압축은 압축 비율이 5:1이면서 그림 무결성이 크게 손실되는 경우도 있습니다.

출처: https://altools.tistory.com/252 [이스트소프트 알툴즈 티스토리 블로그]

 

27. 웹페이지 Redirect의 다양한 구현법에 대해서 설명하라.

 

JavaScript redirects

Redirecting to another URL with JavaScript is pretty easy, we simply have to change the location property on the window object:

window.location = "http://new-website.com";

JavaScript is weird though, there are LOTS of ways to do this.

window.location = "http://new-website.com"; 
window.location.href = "http://new-website.com"; 
window.location.assign("http://new-website.com"); 
window.location.replace("http://new-website.com");

Not to mention you could just use location since the window object is implied. Or self or top.

With the location object we can do a lot of other neat stuff too like reload the page or change the path and origin of the URL.

There are a few problems here:

1. JavaScript needs to be enabled and downloaded/executed for this to work at all.
2. It’s not clear how search engines react to this.
3. There are no status codes involved, so you can’t rely information about the redirect.

What we need is a server side solution to help us out by sending 301 responses to search engines and browsers.

 

출처: css-tricks.com/redirect-web-page/

 

28. Unicode와 UTF-8에 대해서 설명하라

 

1) 유니코드(Unicode)

옛날옛날 컴퓨터가 세상에 나왔을 때는 ‘영어’와 몇가지 ‘특수문자’만 사용했고 이를 저장하기 위해서 1 byte면 충분했다. (0~255) 시간이 흘러 다른 국가 사람들이 컴퓨터를 이용하다보니 자국어도 컴퓨터로 표시하고 싶어졌다. 그래서 1 byte 안에 임의대로 알파벳 대신 자기나라 글자를 할당해서 그럭저럭 쓸 수는 있었다. 그러나 네트워크가 발전하고 다른 사람 홈페이지를 들어갔더니 글자가 와장창 깨지고 만다. 그리하여 국제적으로 전세계 언어를 모두 표시할 수 있는 표준코드를 만들기로 했다. 바로 유니코드(Unicode)다. 참고로, 한글 ‘가’는 유니코드로 ‘U+AC00’이다. 왜 그러냐고 이유는 묻지마라. 약속이다.

유니코드는 글자와 코드가 1:1매핑되어 있는 ‘코드표'이다. (코드표)

2) UTF-8

유니코드를 통해 코드표가 정의되었다. 남은 것은 그 ‘코드'가 컴퓨터에 어떻게 저장되어야 하는 것이다. 다른 말로 인코딩(encoding)이라고 하는데, 컴퓨터가 이해할 수 있는 형태로 바꿔주는 것이다. 예를 들어, 길동이가 자기만의 암호체계를 만들었는데 ‘가'는 0001(=1)로, ‘나'는 0010(=2)이라고 하자. 길동이가 ‘가나나가'라고 말하면 컴퓨터에는 0001 0010 0010 0001로 저장한다. 글자당 1 byte로 할당해 4 byte로 저장할 수 있고 00010010 00100001처럼 2byte로 저장할 수도 있다. 이건 전적으로 길동이와 컴퓨터간의 약속이다. 길동이만 쓸 때는 문제가 없는데 전세계 사람들이 사용하려면 좀 더 잘 만들어야 할것이다.

UTF-8은 유니코드를 인코딩(encoding)하는 방식이다. 전세계에서 사용하는 약속이다.

UTF-8은 가변 인코딩방식이다. 쉬운 말로 하면 글자마다 byte 길이가 다르다는 것이다. ‘a’는 1 byte이고 ‘가'는 3 byte이다. 가변을 구분하기 위해 첫 바이트에 표식을 넣었는데 2 byte는 110으로 시작하고 3바이트는 1110으로 시작한다. 나머지 바이트는 10으로 시작한다. 왜 그러냐고 묻는다면, 그냥 ‘약속이다’라고 말하고 싶다.

출처: 위키피디아

 

29. Map/Reduce에 대해서 설명하라

nomadkim880901.tistory.com/276

30. CSS의 다양한 Selector들에 대해서 설명하라

//셀렉터
h1 { }
div { }

//전체 셀렉터
* { }

//Tag 셀렉터
section, h1 { }

//ID 셀렉터
#only { }

//class 셀렉터
.widget { }
.center { }

//attribute 셀렉터
a[href] { }
p[id="only"] { }
p[class~="out"] { }
p[class|="out"] { }
section[id^="sect"] { }
div[class$="2"] { }
div[class*="w"] { }

//후손 셀렉터
header h1 {}

//자식 셀렉터 (후손 셀렉터와의 차이를 반드시 알고 있어야 합니다)
header > p { }

//인접 형제 셀렉터
section + p { }

//형제 셀렉터
section ~ p { }

//가상 클래스
a:link { }
a:visited { }
a:hover { }
a:active { }
a:focus { }

//요소 상태 셀렉터
input:checked + span { }
input:enabled + span { }
input:disabled + span { }

//구조 가상 클래스 셀렉터 (외울 필요는 없습니다)
p:first-child { }
ul > li:last-child { }
ul > li:nth-child(2n) { }
section > p:nth-child(2n+1) { }
ul > li:first-child { }
li:last-child { }
div > div:nth-child(4) { }
div:nth-last-child(2) { }
section > p:nth-last-child(2n + 1) { }
p:first-of-type { }
div:last-of-type { }
ul:nth-of-type(2) { }
p:nth-last-of-type(1) { }

//부정 셀렉터
input:not([type="password"]) { }
div:not(:nth-of-type(2)) { }

//정합성 확인 셀렉터
input[type="text"]:valid { }
input[type="text"]:invalid { }

31. Multi-Column Index에 대해서 설명하라

 

Multicolumn indexes are indexes that store data on up to 32 columns. When creating a multicolumn index, the column order is very important. This is due to the structure that multicolumn indexes possess. Multicolumn indexes are structured to have a hierarchical structure.

 

32. 비대칭키를 사용한 암호화에 대해서 설명하라

비대칭키 암호(서버가 클라이언트에 전달)

전혀 다른 키 한쌍으로 암호화 및 복호화를 한다.

키 A로 암호화를 한다면 키 B로만 복호화가 가능. 암호화와 복호화에 서로 다른 키를 사용하는 방식.

서버는 키 하나는 보관, 다른 키는 클라이언트에 공개하여 데이터를 안전하게 전달할 수 있게 한다. (공개키 암호화)

 

publickey는 누구나 가지고 있을수 있음에도 이런 방식을 사용하는 이유는 공개키가 데이터 제공자의 신원을 보장해 주기 때문이다.

-암호화된 데이터가 공개키로 복호화 된다는 것은,공개 키와 쌍을 이루는 개인 키에 의하여 암호화 됬다는 것을 의미한다.즉 데이터 제공자의 신원 확인이 보장 된다는 것이다.

 

Hand Shake: 클라이언트는 서버로부터 공개키와 인증서 정보를 받는데, 인증서 정보로 인증된 서버인지 확인한다.

비밀키 부분: 클라이언트는 서버와 비밀 키를 만들어낼 정보를 암호화하여 전송한다. 서버도 마찬가지. 이를 이용하여 비밀키 생성.

상호키 검증: 비밀키를 이용하여 클라이언트가 서버에 암호화된 메세지 전달. 서버가 비밀키를 이용하여 이를 복호화하고 다시 암호화하여 클라이언트에게 보내는데, 클라이언트가 복호화에 성공하면 비밀 키가 성공적으로 만들어졌다는 뜻이다.

=> HTTPS 연결이 성립.

 

 

결론

이렇게 브라우저는 인증서의 도메인과 데이터를 제공한 제공자의 도메인을 비교할 수 있기 때문에 인증서의 도메인 정보와 데이터 제공자의 도메인 정보가 다른 '중간자 공격'을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호할 수 있습니다.

또한 이런 경고를 직접 보여줌으로써 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도합니다.

 

자신의 Private Key만 안전하게 관리하면 Public Key로 암호화되어 안전하게 전송할 수 있다.또한 대칭키는 매번 랜덤으로 선택되는데, 이렇게되면 만약 대칭키가 누출되어도 다음번에는 다른 키가 사용되기 때문에 안전하다.

 

참고: nomadkim880901.tistory.com/438

 

33. Callback Hell을 피할 수 있는 방법에 대해서 설명하라

 

세가지 방법이 있는데 그 중 Promise 패턴 도입이 콜백 문제를 해결할 수 있는 가장 효과적인 방법입니다.

Promise 설명: nomadkim880901.tistory.com/349

 

34. Reflow가 발생하는 이유와 방지 방법에 대해서 설명하라.

 

생성된 DOM 노드의 레이아웃 수치(너비, 높이, 위치 등) 변경 시 영향 받은 모든 노드의(자신, 자식, 부모, 조상(결국 모든 노드) ) 수치를 다시 계산하여(Recalculate), 렌더 트리를 재 생성 하는 과정.

 

또한, Reflow 과정이 끝난 후 재 생성된 렌더 트리를 다시 그리게 되는데 이 과정을 Repaint 라 한다.

 

Reflow 발생 코드:

function reFlow() { 
  document.getElementById('container').style.width = '600px'; 
  return false; 
}

그래프 단계별 설명

1. Click 이벤트 handler 
2. Recalcurate(변경된 스타일 수치 계산 수행) 
3. Layout(Reflow 과정 수행) 
4. Paint(Repaint 과정 수행)

Reflow 과정이 일어나는 상황

• 노드의 추가 또는 제거시. 
• 요소의 위치 변경 시. 
• 요소의 크기 변경 시.(margin, padding, border, width, height, 등..) 
• 폰트 변경 과(텍스트 내용) 이미지 크기 변경 시.(크기가 다른 이미지로 변경 시) 
• 페이지 초기 랜더링 시.(최초 Layout 과정) 
• 윈도우 리사이징 시.

Reflow 최적화 방법

1) 클래스 변화에 따른 스타일 변경 시, 최대한 DOM 구조 상 끝단에 위치한 노드에 주어야 합니다. 

가급적 말단에 위치한 노드 수치 변경 시 리플로우 수행 반경을 전체 노드가 아닌 일부 노드로 제한 시킬 수 있습니다. 

즉, Reflow 수행 비용을 줄일 수 있다는 말과 같습니다.(하지만 실무 작업 시 적용 가능한 범위가 크지 않다) 

 

2) 인라인 스타일을 최대한 배제하라. 

적용 시 코드 가독성과 Reflow 비용을 줄일 수 있습니다. 

 

3) 애니메이션이 들어간 노드는 가급적 position:fixed 또는 position:absolute로 지정하여 전체 노드에서 분리 시키도록 합니다. 

보통 (JS(Javascript) + CSS)를 활용한 에니메이션 효과는 해당 프레임에 따라 무수히 많은 Reflow 비용이 발생하게 됩니다. 

하지만 position 속성을 "fixed" 또는 "absoute"로 값을 주면 지정된 노드는 전체 노드에서 분리됩니다. 

즉, 전체 노드에 걸쳐 Reflow 비용이 들지 않으며, 해당 노드의 Repaint 비용만 들어가게 됩니다. 

또한, 노드의 position 값을 초기에 적용하지 않았더라도 에니메이션 시작 시 값을 변경(fixed, absolute)하고 종료 시 다시 원복 시키는 방법을 사용해도 무관합니다.

 

등등

 

출처: https://webclub.tistory.com/346 [Web Club]
출처: https://mohwaproject.tistory.com/entry/ReflowLayout-과-Repaint-과정-및-최적화 [무하프로젝트]