문제: 알파벳 대소문자로만 이루어진 문자열 my_string이 주어질 때, my_string에서 'A'의 개수, ..., my_string에서 'Z'의 개수, my_string에서 'a'의 개수, ..., my_string에서 'z'의 개수를 순서대로 담은 길이 52의 정수 배열을 return 하는 solution 함수를 작성해 주세요.
.js는 자바스크립트의 파일 확장자이며 일반적으로 사용하는 순수 자바스크립트 코드가 들어간다.
브라우저가 이해할 수 있는 코드이고, 리액트를 쓰지 않아도 문제 없는 파일 형식이다.
[예시 코드]
function sayHello(name) {
console.log("Hello, " + name);
}
sayHello("John");
.jsx 란?
.jsx는 JavaScript XML의 약자이며 자바스크립트 코드 안에 HTML과 비슷한 문법을 쓸 수 있게 해주는 확장자이다.
주로 React에서 사용되며, JSX 문법을 사용하면 마치 HTML처럼 UI를 구성할 수 있다.
하지만 브라우저는 JSX를 이해하지 못하므로 컴파일 변환이 필요하다.
* .js에서도 JSX 문법을 사용할 수는 있음!
[개념 알고가기 💡] 1. XML(eXtensible Markup Language)이란? 확장 가능한 마크업 언어로, HTML처럼 태그로 데이터를 표현하지만 HTML보다 훨씬 더 유연하고 데이터 중심적이다. 원래는 데이터 저장/전송용 포맷으로 만들어졌으며, 특징은 다음과 같다. 1) 사용자가 직접 태그를 정의 가능 2) 구조적 데이터 표현에 적합 3) 사람도 읽기 쉽고, 기계도 파싱하기 쉬움 * 단순히 데이터를 표현하는 방법이며, 실제 동작은 하지않고 데이터를 설명하는 "형식"이다.
* 따라서 JSX는 JavaScript XML이란 이름이지만, 실제로는 XML이 아니고XML처럼 생긴 문법을자바스크립트에 끼워 넣은 것이다.
[예시 코드]
export default function Hello() {
return <h1>Hello, world!</h1>;
}
.js 확장자에서도 JSX 문법을 사용할 수 있는데, 왜 굳이 .jsx로 사용하면서 컴파일 변환을 해줘야하는거지?
.js에서도 JSX를 사용할 수 있는 이유
그 이유는 Babel이나 Webpack 같은 빌드 도구가 .js 파일 안에서도 JSX 문법을 인식하고 변환해줄 수 있게 설정되어 있기 때문이다.
그렇기 때문에 .js 파일에서 JSX 문법을 사용한다해도, 브라우저는 애초에 JSX를 이해하지 못하기 때문에 컴파일 변환은 일어난다.
그렇다면 .jsx로 확장자를 지정해주는 이유는 뭘까?
1) 가독성: JSX가 들어있다는 걸 파일 이름만 보고 바로 알 수 있다.
2) 협업: 다른 개발자에게 "이 파일은 리액트 컴포넌트입니다"라는 신호를 준다.
3) 에디터 지원: .jsx 파일은 대부분의 에디터가 JSX 문법 강조를 더 잘 지원한다.
=> 즉, 기술적으로 꼭 .jsx를 써야 하진 않지만, 명확한 의도를 전달하는 좋은 습관이 될 수 있다!
그렇다면 컴파일 변환은 어떻게 일어나는 걸까?
JSX의 컴파일 흐름
1) JSX 코드 작성
const element = <h1>Hello</h1>;
2) Babel이 JSX 코드를 자바스크립트로 변환
const element = React.createElement("h1", null, "Hello");
문제: 랜덤으로 서로 다른 k개의 수를 저장한 배열을 만드려고 합니다. 적절한 방법이 떠오르지 않기 때문에 일정한 범위 내에서 무작위로 수를 뽑은 후, 지금까지 나온적이 없는 수이면 배열 맨 뒤에 추가하는 방식으로 만들기로 합니다. 이미 어떤 수가 무작위로 주어질지 알고 있다고 가정하고, 실제 만들어질 길이 k의 배열을 예상해봅시다.
정수 배열 arr가 주어집니다. 문제에서의 무작위의 수는 arr에 저장된 순서대로 주어질 예정이라고 했을 때, 완성될 배열을 return 하는 solution 함수를 완성해 주세요. 단, 완성될 배열의 길이가 k보다 작으면 나머지 값을 전부 -1로 채워서 return 합니다.
렌더링 방식은 화면을 만들기 위한 데이터와 구조(HTML)을 누가 언제 준비하냐에 따라 다르다.
각 렌더링 방식에 대한 느낌을 정리해보자면 다음과 같다.
CSR은 "브라우저야, 이 JS로 페이지를 직접 만들어!"
SSR은 "서버가 만들어줄게. 브라우저는 그냥 보여줘!"
SSG는 "미리 만들어둘게. 나중에 그냥 보여줘!"
그렇다면 각 렌더링 방식에 대해 자세히 알아보자!
CSR(Client Side Rendering)이란?
클라이언트에서 페이지 내용을 만드는 방식으로, 사용자의 브라우저가 서버로부터 데이터를 받아와서 웹 페이지를 직접 생성한다.
[CSR의 동작 과정] 1) 사용자가 웹 사이트에 접속하면 서버는 빈 HTML과 JavaScript 파일을 보냄. 2) 브라우저가 JavaScript를 로드하고 실행 3) JavaScript가 동적으로 HTML을 생성하고, 이를 브라우저에 표시 4) 추가 페이지 요청 시, 전체 페이지를 다시 로드하는 대신에 필요한 데이터만 서버에서 받아와 해당 부분만 업데이트 → 즉, CSR은 서버로부터 빈 접시(빈 HTML)와 요리 재료(JavaScript)를 받고 요리(렌더링)를 직접 하는 방식
그럼 CSR을 사용했을 때의 장점과 단점은 뭘까?
SSR(Server Side Rendering)이란?
서버에서 HTML을 완성시킨 후 브라우저로 보내는 방식이다.
[SSR의 동작 과정] 1) 사용자가 웹 사이트에 접속하면 서버에서 해당 페이지에 필요한 HTML 생성 2) 서버는 생성된 HTML을 브라우저로 보낸다. 3) 브라우저는 받은 HTML을 표시 4) 추가 페이지 요청 시, 해당 페이지에 대한 HTML을 다시 서버에서 생성하여 보낸다. → 즉, SSR은 서버에서 요리(웹 페이지 렌더링)를 완성시킨 후 접시에 담아서(완성된 HTML) 손님(사용자)에게 제공하는 방식
그럼 SSR을 사용했을 때의 장점과 단점은 뭘까?
SSG(Static Site Generation)란?
미리 HTML을 만들어두고 요청이 오면 바로 보여주는 방식이다.
[SSG의 동작 과정] 1) 빌드 시 프레임워크는 모든 경로에 대한 HTML 파일을 미리 생성한다. 2) 사용자가 웹 사이트에 접속하면, 서버는 미리 생성해둔 HTML을 보낸다. 3) 브라우저는 받은 HTML을 표시 4) 추가 페이지 요청 시, 미리 생성해둔 해당 페이지의 HTML을 보낸다. → 즉, SSG는 미리 요리(웹 페이지 렌더링)를 완성시켜놓고, 동일한 요리를 계속 제공하는 방식