리액트 강좌

3-1.개발툴 활용

성적표 앱

프로젝트의 골격은 대충 익혔다. 이 골격을 활용하여 예제를 만들고 리액트를 연구해 보되 실질적으로 수정해야 할 소스는 App.tsx 밖에 없다. study라는 이름으로 실습용 통합 프로젝트를 만들고 이 안에 소스를 계속 작성해 보자.

프로젝트의 골격은 같고 바뀌는 부분은 극히 일부이므로 프로젝트 하나에 코드를 계속 작성하는 방식이 편리하다. 앞에서 만든 firstvite가 실행중이면 종료하고 상위 디렉토리로 이동한 후 새 프로젝트를 만든다.

C:\reactStudy\firstvite>cd..

C:\reactStudy>npm create vite@latest

상위 디렉토리로 이동하지 않으면 프로젝트안에 프로젝트를 만들게 된다. 그래도 문제는 없지만 관리가 어려워지니 모든 예제는 C:\reactStudy 아래에 만들자. 프로젝트 이름은 study로 지정하고 React 프레임워크에 TypeScript를 선택한다.

설치 및 실행(Install with npm and start now) 옵션을 선택하여 일단 실행한 후 종료해도 되고 아니면 study 폴더로 들어간 후 npm install 명령을 내려 설치만 해도 된다. 프로젝트 초기화 후 VSCode에서 폴더를 열면 작성 준비 완료이다. App.tsx에 앞서 JSX를 소개할 때 보인 예제를 만들어 보자.

import './App.css'

function App() {

let score = 123;

return (

<div>

<p id="result">점수는 {score}입니다.</p>

</div>

)

}

export default App;

템플릿에 있는 소스는 모두 지우고 꼭 필요한 코드만 작성했다. 프로젝트 디렉토리 안으로 들어가 실행해 보자.

C:\reactStudy>cd study

C:\reactStudy\study>npm run dev

JSX 안에 <h2>, <p> 태그를 배치하고 문단안에 score 변수를 표시했다. 웹 브라우저가 열리고 두 개의 문단으로 된 성적표 페이지가 나타난다.

브라우저는 기본으로 설정된 것이 열리는데 가급적 크롬으로 확인해 보자. 다른 브라우저로 확인해 보고 싶으면 http://localhost:5173 주소를 복사하여 이동하면 된다.

에러 처리

개발이 항상 순조롭게 잘 되기만 하는 것은 아니다. 학습중에는 아직 익숙하지 않아 오타를 입력할 경우도 많고 제대로 했는데 결과가 나오지 않는 상황도 흔하게 만날 수 있다. 이럴 때는 개발툴의 도움을 잘 받아야 한다.

개발중이나 학습중에는 변수값 확인과 코드의 흐름을 살펴볼 필요가 있으며 이때는 보통 로그를 찍어 본다. 코드 중간에 로그 출력문을 넣어 score 변수가 값을 제대로 가지고 있는지 확인해 보자. App.tsx의 코드를 다음과 같이 수정한다.

import './App.css'

function App() {

let score = 128

console.log("현재 점수 : " + score)

return (

<div>

<p id="result">점수는 {score}입니다.</p>

</div>

)

}

export default App;

console.log의 인수열에 확인해 보고 싶은 변수를 적는다. 웹브라우저는 개발자 도구를 제공하는데 크롬, 엣지 모두 단축키는 F12이다. 개발자 도구의 Elements 탭에서 DOM 구조를 확인하고 Console탭에서 에러를 확인한다.

로그가 두 번 찍히는 이유는 엄격 모드(<StrictMode>)에서 디버깅을 위해 랜더링을 두 번씩 하도록 되어 있기 때문이다. 엄격 모드를 제거하면 로그가 한번만 나오지만 어차피 확인만 하면 되니 두 번씩 찍혀도 별 상관은 없다.

개발중에 오타는 피할 수 없는 숙명이다. 긴 코드 중간에 의도치 않게 들어간 오타로 인해 실행이 안되는 경우가 허다하다. 이럴 때 오타를 어떻게 잡는지 실습해 보자. 로그 출력문에 의도적으로 오타를 내 본다.

consol.log("현재 점수 : " + score)

consol에서 마지막 e를 빼 먹었다. VSCode는 편집기일 뿐 컴파일러가 아니므로 이것이 오타인지 확인해 주지 않는다. 대신 ESLint 플러그인에 뭔가 이상하다는 의미로 빨간 줄을 그어 보여 준다.

그러나 이 빨간줄만 봐서는 뭐가 잘못된 것인지 바로 눈치채기 어렵다. 이 상태에서 소스를 저장하면 재실행되면서 브라우저의 로그창에 에러 메시지가 나타난다.

5행 3열에 있는 consol이 정의되지 않았다는 뜻이다. 이 메시지를 통해 오타를 확인하고 수정 후 저장하면 된다. 자바스크립트는 컴파일 방식으로 일괄 번역하지 않고 번역하면서 실행하는 방식이라 실행중에 에러가 발생한다. 편집창, 브라우저, 콘솔 등 여러 곳에서 에러에 대한 정보를 제공해 준다.

뭔가 뜻대로 되지 않으면 항상 콘솔창을 확인해 봐야 한다. 오타를 수정해서 저장하면 즉시 해결된다. e을 다시 삽입하여 오타를 바로 잡고 저장하면 깔끔하게 수정된다.

package.json

프로젝트의 구성 정보는 프로젝트 디렉토리 루트에 있는 package.json에 기록되어 있다. 프로젝트 이름과 버전, 종속성 정보가 명시되어 있는데 프로젝트 생성 시점에 따라 실제 모습은 조금씩 다르다. 오픈소스는 발전이 워낙 빨라 늦게 만든 프로젝트일수록 패키지의 버전이 높다.

{

"name": "study",

"private": true,

"version": "0.0.0",

"type": "module",

"scripts": {

"dev": "vite",

"build": "tsc -b && vite build",

"lint": "eslint .",

"preview": "vite preview"

"dependencies": {

"react": "^19.2.0",

"react-dom": "^19.2.0"

"devDependencies": {

"@eslint/js": "^9.39.1",

"@types/node": "^24.10.1",

"@types/react": "^19.2.5",

"@types/react-dom": "^19.2.3",

"@vitejs/plugin-react": "^5.1.1",

"eslint": "^9.39.1",

"eslint-plugin-react-hooks": "^7.0.1",

"eslint-plugin-react-refresh": "^0.4.24",

"globals": "^16.5.0",

"typescript": "~5.9.3",

"typescript-eslint": "^8.46.4",

"vite": "^7.2.4"

}

name, private, version 필드는 이 프로젝트의 속성이다. name은 생성할 때 준 프로젝트 이름이며 study로 지정되어 있다. private는 프로젝트의 공개 여부를 지정하는데 디폴트는 true여서 비공개이다. 누구나 쓸 수 있도록 공개할 오픈소스 프로젝트이거나 전사적으로 재사용 가능한 모듈일 때 false로 설정한다.

공개 프로젝트는 패키지 관리 시스템을 통해 다른 개발자에게 배포할 수 있다. 사용자에게 직접 배포할 최종 프로젝트인 경우는 굳이 공개할 필요 없으므로 이 속성을 true를 지정하여 사적 프로젝트로 생성한다. version은 처음 만들었다는 의미로 0.0.0으로 초기화되어 있다.

type은 프로젝트의 모듈 시스템을 지정하는데 이 값을 module로 지정하면 최신 표준인 ESM을 따른다는 뜻이며 export, import 키워드를 사용한다. 이 지정이 없으면 ES6 이전의 require 구문을 사용하는데 지금은 그럴 필요가 전혀 없다.

scripts 섹션은 자주 사용하는 명령의 별칭을 정의하며 npm run 다음에 별칭을 쓰면 그 뒤의 명령을 실행한다. 이 별칭이 정의되어 있기 때문에 npm run dev 명령으로 프로젝트를 실행할 수 있다. 이 명령은 npx vite로 바뀌어 실행된다. 나머지 스크립트 명령에 대해서는 천천히 알아 보자.

dependencies 섹션에는 프로젝트에 사용할 패키지와 버전을 지정한다. 버전에 1.2.3과 같이 숫자를 명확히 적으면 해당 버전만 사용하라는 뜻이다. 패키지가 계속 업데이트되므로 굳이 특정 버전을 고정할 필요는 없고 어느 정도 융통성을 발휘하는데 기호에 따라 허용 범위가 다르다.

기호	설명
^	마이너 버전까지는 바뀌더라도 업데이트 가능하다. ^1.2.3으로 지정했는데 1.4.5가 나왔다면 이 버전을 쓴다. 앞자리가 2.0.0이 되면 이 버전으로 업데이트하지는 않는다.
~	패치 버전까지는 업데이트 대상이다. ~1.2.3으로 지정한 경우 1.2.9까지의 패치 버전까지는 쓴다.
*	모든 버전을 허용하며 가장 최신 버전을 적용한다. 문제 발생 소지가 많아 권장하지 않는다.
>, <, >=, <=	지정한 버전보다 높거나 낮은 버전을 허용한다. 더 높은 버전을 쓸 수 없는 경우도 있다.
-	버전의 범위를 지정한다. 1.2.3 - 1.5.0으로 지정하면 이 범위 내에서 최신 버전을 사용한다.
\|\|	상기의 여러 규칙을 조합한다. ^1.2.3 \|\| 2.3.4는 1.x.x를 허용하고 2.x.x는 허용하지 않되 2.3.4는 허용한다.

대부분의 패키지는 ^으로 버전이 지정되어 있다. react 버전을 ^19.2.0으로 지정하면 19.9.9까지는 업데이트해도 된다는 뜻이다. 그러나 리액트 20.0.0이 나왔더라도 이 버전을 쓰지는 않는다. 만약 20.0.0을 쓰고 싶다면 버전을 직접 편집하고 잘 실행되는지도 테스트해야 한다.

devDependencies는 개발 환경에서만 사용하는 라이브러리이다. 앞에 @기호가 붙어 있는 것은 패키지를 만든 조직을 명시하여 그룹화하고 이름 충돌을 방지한다. 조직명 뒤의 / 다음이 패키지 이름이다. eslint나 typescript 등은 개발중에만 필요할 뿐 실제 제품에 포함할 필요는 없다.

패키지의 버전이 가변적이다 보니 융통성은 있지만 차칫하면 버전간 호환성이 맞지 않아 문제가 생길 위험이 있다. 버전을 ^1.2.3으로 지정했는데 더 최신 버전인 1.3.0이 나왔을 때 이걸 적용하면 개발했을 때와는 조금이라도 달라질 가능성이 다분하다. 오픈소스가 원래 하위 호완성을 잘 지키지 않는다.

이런 문제를 해결하기 위해 npm 버전 5부터는 정확한 의존성 정보를 기록하는 package-lock.json을 따로 관리한다. 이 파일 안에는 빌드시에 사용한 정확한 버전을 명시하여 이 정보를 바탕으로 빌드하면 최종 빌드시와 똑같이 만들 수 있음을 보장한다. 이 파일은 툴이 자동으로 생성해 내므로 수동으로 편집해서는 안된다.

새로운 패키지를 설치했거나 package.json이 바뀔 때 npm install 명령으로 재생성해 주면 된다. 이 파일도 버전 관리 대상이며 저장소에 올려 두어야 다른 개발자가 똑같은 빌드 환경을 구축할 수 있다. 동료가 패키지를 추가했다면 나도 소스를 받아 추가한 패키지를 다운로드받아 싱크를 맞춘다.

패키지 관리자

study 프로젝트는 아주 단순한 기능만 구현했지만 용량은 100M에 달한다. 그 이유는 빌드에 필요한 패키지를 node_modules 폴더 내에 모두 내장하고 있기 때문이다. 그렇다면 이 프로젝트를 백업해 두거나 다른 사람에게 전달하려면 통째로 압축해서 보내야할까? 다행히 그렇지는 않다.

node_modules 폴더는 언제든지 재구성할 수 있으므로 지워 버려도 된다. 이 폴더를 지우면 프로젝트 폴더는 고작 1M도 안된다. package.json에 어떤 패키지가 필요한지 모두 기록되어 있어 빌드하기 전에 다음 명령으로 재설치하면 된다.

C:\reactStudy\study>npm install

패키지 관리자는 리액트 프로젝트 구성에 필요한 패키지를 관리하는 역할을 한다. 주요 명령어를 정리해 보자.

명령	설명
npm -v	버전 및 설치 여부 확인
npm install	패키지 설치
npm uninstall	패키지 삭제
npm update	패키지 최신 버전으로 업데이트
npm run	package.json의 scripts 섹션에 정의된 스크립트 실행

연습삼아 자바스크립트의 배열, 객체를 다루는 유틸리티 라이브러리인 loadash를 설치해 보자. 이때는 잠시 실행을 중지하는 것이 좋다. 단순 유틸리티 패키지는 실행중에 설치하는 것도 가능은 하지만 환경을 바꾸는 패키지는 정상 동작을 보장할 수 없으므로 종료 후 설치하고 재시작하는 것이 바람직하다.

C:\reactStudy\study>npm install lodash

added 1 package, and audited 178 packages in 1s

45 packages are looking for funding

run `npm fund` for details

found 0 vulnerabilities

node_mudules 폴더에 lodash 관련 패키지가 설치되며 package.json의 dependencies 섹션에도 기록된다. 이후 node_mudules를 다 지원도 언제든지 재설치할 수 있다.

"dependencies": {

"lodash": "^4.17.21",

"react": "^19.2.0",

"react-dom": "^19.2.0"

설치 해제 명령은 npm uninstall loadsh이며 이 명령을 내리면 의존성도 제거된다. npm은 노드의 기본 패키지 관리자여서 노드와 함께 설치되어 간편하게 쓸 수 있다. 더 발전된 다른 패키지 관리자도 있지만 당분간은 npm에 익숙해지자.

빌드

package.json의 "scripts" 란에는 개발중에 사용할 스크립트가 작성되어 있는데 다음 4가지 동작이 정의되어 있다. 이 명령은 리액트 스크립트로 동작하는 일종의 실행 파일이며 npm으로 바로 호출할 수 있다.

명령	설명
npm run dev	프로젝트를 실행한다.
npm run build	프로젝트를 배포 가능한 상태로 빌드한다.
npm run lint	소스를 점검하여 잠재적인 문제를 검사한다.
npm run preview	빌드한 배포용 코드를 로컬에서 미리 확인한다.

스크립트를 실행할 때는 npm run 다음에 명령어를 전달한다. dev는 개발 모드에서 프로젝트를 실행하라는 뜻인데 일종의 디버그 모드로 돌리며 테스트하는 것이다.

이에 비해 빌드는 배포를 위해 웹 서버가 바로 실행할 수 있는 파일을 만들어낸다. build명령은 tsc -b && vite build로 정의되어 있는데 tsc -b는 타입스크립트가 언어 차원에서 오류가 없는지 확인한다. 오류가 없으면 vite가 Rollup 번들러를 호출하여 실행에 필요한 파일을 모으고 압축하고 최적화까지 수행한다. 과연 어떤 파일이 만들어지는 빌드해 보자.

C:\reactStudy\study>npm run build

> study@0.0.0 build

> tsc -b && vite build

vite v7.2.7 building client environment for production...

✓ 29 modules transformed.

dist/index.html 0.45 kB │ gzip: 0.29 kB

dist/assets/index-DQ3P1g1z.css 0.91 kB │ gzip: 0.49 kB

dist/assets/index-CD5vsBHE.js 193.50 kB │ gzip: 60.79 kB

✓ built in 472ms

웹 배포용 파일을 빌드하고 dist 폴더에 번들링한 파일을 생성한다. 어떤 파일을 생성해 놨는지 살펴 보자. index.html은 기본 구조만 가지고 스크립트 파일에 실제 내용을 작성한다. 스크립트 파일, 스타일 파일은 assets 폴더 안에 있다.

index-CD5vsBHE.js 이런 형태로 작성하는데 캐시 방지를 위해 해시 코드를 붙인다. 내용이 조금이라도 바뀌면 해시도 바뀌어 브라우저의 캐시를 무효화하는 역할을 한다. 어떤 코드가 작성되어 있는지 열어 보자.

다운로드 용량을 줄이기 위해 개행은 전혀 없고 공백도 꼭 필요한 것만 남기고 다 지워 버렸다. 그나마 HTML이나 CSS는 좀 불편해도 읽을만 하지만 스크립트는 거의 판독이 불가할 정도로 압축되어 있다.

사람이 보기에는 욕나오지만 컴퓨터는 오히려 이런 파일을 더 좋아한다. 다운로드할 양이 줄어들어 기동 속도도 빠르다. 이래서 개발용과 배포용을 굳이 구분하는 것이다. 빌드한 결과를 웹 서버에 올려 실행하는데 개발에서 사용하는 것보다 더 가벼운 웹 서버가 필요하다. 경량 서버를 실행하여 배포본을 미리 점검하는 명령이 preview이다.

C:\reactStudy\study>npm run preview

> study@0.0.0 preview

> vite preview

➜ Local: http://localhost:4173/

➜ Network: use --host to expose

➜ press h + enter to show help

개발과 똑같이 실행되며 이상 없는지 확인한다. 이상없음을 확인한 후에는 실제 웹 서버에 올려 프로젝트를 배포한다. 학습중에는 굳이 빌드까지 해 볼 필요없이 npm run dev로 결과만 확인해 보면 된다.

배포 예제

이후 리액트 학습을 위해 수많은 예제를 만들어 보고 수정해 봐야 한다. 다행히 리액트는 소스를 수정하고 결과를 확인하는 과정이 굉장히 쉽다. 수정 후 저장만 하면 변경된 결과를 브라우저에 바로 출력한다.

VSCode와 크롬을 나란히 두고 코드만 수정한 후 저장하면 브라우저에 결과가 바로 나타나니 편리하게 공부할 수 있다. score 변수를 98점으로 수정하고 저장해 보자. 소스가 변경되는 즉시 ESM 모듈에 의해 변경된 부분만 재배포하고 브라우저의 새로고침까지 해 준다. 1초도 안걸린다.

상당히 재미있는데 98점을 다시 123점으로 바꾼 후 또 저장해 보자. 신기할 정도로 빠르고 정확하다. 저장만 하면 바로 결과를 신속하게 볼 수 있어 학습하기 편리하다.

리액트 프로젝트의 구조는 거의 동일하며 변경이 필요한 부분은 App.tsx 안의 코드뿐이다. 이제부터 App.tsx를 수정해 가며 문법을 연구해 봐야 하는데 매번 새로 프로젝트를 만들기는 귀찮고 비효율적이다. study 프로젝트의 App.tsx에 코드를 수정해 가며 실습하는 것이 빠르다.

배포 프로젝트의 App.tsx 파일에는 각 예제가 실습 순서대로 작성되어 있되 시작 부분은 /*로 끝 부분은 //*/ 주석으로 감싸져 있다. 실행해 볼 예제의 주석 첫 부분에 / 하나만 넣으면 즉시 실행해 볼 수 있다. 소스 선두에는 공통적으로 사용하는 import 구문이 있고 제일 끝에는 App 컴포넌트를 외부로 공개하는 export default App; 선언이 있다.

import React from 'react';

//*

예제 1

//*/

예제 2

//*/

export default App;

주석 시작 부분에는 간단한 설명이 작성되어 있고 이름이 있는 예제는 이름:설명 형식으로 작성해 두었다. 이 형식으로 study 프로젝트에 이 책의 모든 예제가 다 포함되어 있다. 책을 읽는 시점에는 프로젝트의 구조가 달라질 수 있는데 이 경우 새로 프로젝트를 생성한 후 App.tsx와 App.css만 복사해 넣으면 최신 버전에서도 예제를 실행해 볼 수 있다.

직접 코드를 타이핑해가며 공부하는게 시간은 걸리지만 꼼꼼히 살펴볼 수 있고 코드의 구조에도 익숙해질 수 있어 바람직하며 권장하는 바이다. 시간이 넉넉치 않다면 배포 예제를 활용하여 빠른 속도로 학습하되 그렇다고 해서 건성으로 읽기만 하면 안되고 어디가 어떻게 바뀌었는지는 잘 관찰해 보자. 예제 하나를 볼 때마다 차분하게 정리하고 넘어가야 하며 그러다 보니 공부에는 원래 시간이 많이 걸린다.

vite로 생성한 프로젝트의 기본 스타일은 중앙 정렬에 흰 바탕으로 되어 있다. 화면에서 보기에는 무난하지만 지면이나 강좌에 실행 결과로 보기에는 여백과 잘 구분되지 않아 가독성이 떨어진다. 그래서 App.css의 #root 스타일을 다음과 같이 수정해 두었다.

#root {

max-width: 1280px;

margin: 0 auto;

padding: 1rem;

text-align: left;

background-color: rgb(224, 224, 224);

}

실행 결과를 캡쳐했을 때 컴포넌트 영역을 분명히 표시하기 위해 바탕색은 옅은 회색으로 지정하고 문자열은 왼쪽 정렬했다. 안쪽 여백은 1단위(=16px)만큼 띄운다.

이후 지면에서는 내용 파악과 무관한 브라우저 프레임은 생략하고 회색의 컴포넌트 영역만 캡처해서 보인다.

3-2.JSX 문법

트랜스파일러

웹은 학술 논문 공유용으로 개발되었으며 정적인 문서만 보여 주면 충분했다. 요즘의 웹은 실시간으로 계산한 정보를 동적으로 생성하여 보여 준다. DB에서 읽은 값이든, 사용자가 선택한 값이든 다 실행중에 결정되는 값이어서 코드로 문서를 생성하여 보여 주어야 한다.

제목이나 레이아웃 외의 거의 모든 내용은 다 실행중에 계산한 것이다. 네이버를 보면 항상 같은 건 없고 뉴스나 광고나 매번 바뀐다. 실행중에 뭔가를 만들어 내려면 결국 코딩을 해야 한다. 1장에서 순수 자바스크립트로 만든 예제를 보인 적이 있는데 다시 한번 더 살펴 보자.

score.html

<!DOCTYPE html>

<html>

<head>

<title>sample</title>

</head>

<body>

// 출력할 점수

let score = 123

// <h2> 태그 생성

let head = document.createElement("h2");

head.setAttribute("class","head")

let text = document.createTextNode("성적표");

head.appendChild(text);

// 루트에 <h2> 태그 추가

let root = document.getElementById("root")

root.appendChild(head);

// <p> 태그 생성

let para = document.createElement("p");

para.setAttribute("id","result")

let textpara = document.createTextNode("점수는" + score + "입니다.");

para.appendChild(textpara);

// 루트에 <p> 태그 추가

root.appendChild(para);

</script>

</body>

</html>

HTML 파일은 브라우저에서 직접 열어 결과를 확인한다. 이 예제의 score 변수는 외부에서 주어지는 가변적인 값이다. 노드 만들고 속성 설정하고 노드끼리 연결하는 모든 작업을 함수 호출로 처리한다. score 변수값을 문단에 집어 넣는 것도 마찬가지이다. 리액트를 쓰지 않았지만 실행 결과는 같다.

어려운 코드는 아니지만 너무 길고 복잡하다. 일일이 타이핑하면 생산성 떨어지고 오타의 위험도 높다. 이보다 더 편리한 방법이 필요한데 그게 바로 리액트이다. study 프로젝트에 이미 성적표를 생성하는 JSX 구문이 작성되어 있는데 이 구문을 함수 호출문으로 바꿔 보자. 코드는 App에만 작성하면 된다. 이 안에서 React 패키지의 기능을 사용하므로 React를 임포트한다.

import React from 'react';

import './App.css';

function App() {

let score = 123

return (

React.createElement('div', null,

React.createElement('h2', { className: 'head' }, '성적표'),

React.createElement('p', { id: 'result' }, '점수는 ' + score + '입니다.')

)

}

export default App;

JSX는 사용하지 않고 함수 호출과 순수한 자바스크립트만으로 작성했다. 리액트의 createElement 메서드를 호출하여 엘리먼트를 만들되 자식 엘리먼트까지 한꺼번에 생성했다. 이렇게 만든 App 컴포넌트를 div root에 붙여 랜더링한다. 앞 예제와 실행 결과는 같지만 노드를 만들 때 사용한 함수가 다르다는 점을 주의하자.

자바스크립트 : document.createElement

리액트 : React.createElement

전자는 브라우저가 바로 인식할 수 있는 노드를 생성하며 appendChild로 어느 노드 밑에나 추가할 수 있다. 이에 비해 후자는 메모리상에만 존재하는 노드 객체를 생성하며 브라우저가 직접 인식하지 못한다. 그래서 실제 노드로 바꿔 화면 그리는 render 함수가 필요하다. App 컴포넌트를 랜더링하는 코드는 main.tsx에 이미 작성되어 있다.

createRoot(document.getElementById('root')!).render(

<App />

</StrictMode>,

)

리액트의 가상 DOM 생성 구문은 자바스크립트에 비해 축약적이고 짧지만 그래도 함수명이 길고 일일이 객체로 감싸야 하므로 생산성이 떨어지기는 매한가지이다. 이걸 더 짧게 줄여 꼭 필요한 정보만 간략하게 기술하자는 아이디어가 바로 JSX이다. JSX로 바꾸면 study 프로젝트의 처음에 만들었던 코드가 된다.

function App() {

let score = 123

return (

<div>

<p id="result">점수는 {score}입니다.</p>

</div>

)

}

함수 호출문 따위는 없고 만들고자 하는 태그명과 속성, 문자열로만 구성되어 있다. 마치 HTML 문서를 만들듯 짧고 간략하게 내용만 기술하면 되니 쓰기 편하고 읽기 좋고 확장하기도 편리하다.

문제는 JSX가 웹표준이 아니라는 점이다. HTML처럼 생겼을 뿐 같지는 않아 브라우저가 이 문서를 표시할 수 없다. 게다가 자바스크립트도 아니어서 실행엔진도 인식하지 못한다. JSX는 HTML과 자바스크립트를 동시에 표현할 수 있는 고유의 문법을 가지는 XML 문서일 뿐이다.

누군가가 JSX를 자바스크립트 실행엔진이 이해할 수 있는 코드로 번역해야 한다. 그 역할을 하는 주체가 트랜스파일러이다. 컴파일러는 소스를 이진 파일로 번역하는데 비해 트랜스파일러는 소스를 다른 소스로 번역한다. JSX는 트랜스파일러에 의해 자바스크립트 코드로 바뀌고 리액트가 이 코드를 실행하여 HTML 문서 만들고 브라우저에 보이게 된다.

JSX 구문에 있는 <div>, <h2>, <p>는 태그가 아니라는 것을 이해해야 한다. 이런 태그를 생성하는 함수 호출문으로 번역되는 일종의 컴포넌트이다. 외우기 쉽도록 가급적이면 HTML 태그와 같은 이름으로 해 놓았고 HTML로 바꾸기 쉬운 객체일 뿐이다.

트랜스파일러는 또한 최신 자바스크립트 문법을 예전 브라우저가 실행할 수 있는 구형 문법으로 변환하여 호환성을 높이는 역할도 한다. JSX를 자바스크립트로 변환하는 트랜스파일러도 여러 가지가 있다.

▶바벨(Babel) : 원조 트랜스파일러이며 한동안 표준이었다. 호환성이 뛰어나고 유연하지만 속도가 느리다.

▶SWC(Speedy Web Compiler) : 타입스크립트를 처리할 수 있고 Rust로 작성되어 속도가 빠르다.

▶TSC(TypeScript Compiler) : 타입스크립트를 자바스크립트로 번역하는 것이 본연의 기능이지만 JSX 변환도 지원한다.

▶ESBuild : Go 언어 기반이며 초고속으로 번역한다. 바벨보다 최소 10배, 최대 100배까지 빠르다.

어떤 트랜스파일러를 사용할 것인가는 프로젝트 설정에 따라 달라진다. CRA는 바벨을 사용하여 번역 속도가 느렸다. vite는 모드나 설정에 따라 최적화된 방법을 선택한다. 개발에는 ESBuild를 사용하여 빠른 속도에 중점을 둔다. 프로덕션에는 Rollup 번들러가 바벨이나 SWC를 플러그인 형태로 사용하여 번역 뿐만 아니라 최적화된 번들링까지 수행한다.

여기서 중요한 것은 JSX가 그냥 실행되는게 아니라 어떤 형태든 트랜스파일러를 거쳐 번역되고 번들링된다는 점이다. 결국에는 브라우저가 이해할 수 있는 태그로 바뀌어 웹 페이지에 표시해야 한다.

유일한 루트

JSX 안에서는 고유의 엄격한 문법이 적용된다. 가급적 HTML과 비슷하게 만들어 놓았으나 근본적으로 언어가 다르니 적용되는 규칙도 다르다. 어떤 것이 되고 안되는지 상세히 알아야 한다. 리액트의 가장 기초적인 규칙이라 다 암기하고 습관이 들어야 한다. 그렇지 않으면 "이게 왜 안되지?"하고 갸웃갸웃 할 때가 꼭 있을 것이다.

study 프로젝트의 JSX 구문을 수정해 가며 어떤 규칙이 있는지 실습해 보자. JSX 구문은 결국은 웹페이지에 보일 태그를 정의한다. 태그가 하나 뿐이라면 그 태그를 리턴하면 된다. 성적표에서 제목은 빼고 성적 자체만 출력하겠다면 다음과 같이 적으면 되고 이상없이 잘 출력된다.

function App() {

let score = 123

return (

<p id="result">점수는 {score}입니다.</p>

)

}

<p> 태그가 가상 DOM의 루트가 되며 졸개는 없는 단독 대장이다. 그러나 태그가 두 개 이상일 때는 규칙이 달라진다. 제목을 다시 추가해 보자.

function App() {

let score = 123

return (

<p id="result">점수는 {score}입니다.</p>

)

}

이건 안된다. 웹페이지에는 에러가 잔뜩 나타난다. 개발 버전이라 어디가 잘못되었는지 알려준다.

인접한 태그는 반드시 하나의 태그로 감싸야 한다고 되어 있다. JSX로 생성하는 가상 DOM은 유일한 루트 노드가 있어야 한다. 얼마든지 많은 태그를 포함할 수 있지만 그 모두를 포함하는 대장이 존재해야 한다. 첫 예제에는 h2와 p를 감싸는 div 태그를 상위에 적어 주었다.

function App() {

let score = 123

return (

<div>

<p id="result">점수는 {score}입니다.</p>

</div>

)

}

이때 div 태그는 h2와 p를 묶는 부모의 역할을 할 뿐 화면에 보이지도 않고 아무 기능도 없다. 이런 용도라면 어떤 태그든 상관 없다. section, article, header 등의 블록 태그도 가능한데 의미론적 용도가 정해져 있을 뿐 div와 거의 같다. 심지어 실제 폰트가 바뀌는 부작용이 있더라도 b, i, u 같은 태그도 루트로 쓸 수 있다.

<div>는 아무 기능이 없어도 어쨌건간에 노드이므로 약간 손해를 본다. 어차피 차일드를 묶는 용도로만 사용한다면 빈 태그를 쓸 수도 있다. 리액트는 이런 용도로 React.Fragment 태그를 제공한다. 태그 이름이 너무 길다면 <> </>로 줄여 쓰는 방법도 제공하며 import 없이도 쓸 수 있어 이 방법이 제일 간단하다.

import React from 'react';

function App() {

let score = 123

return (

<React.Fragment>

<p id="result">점수는 {score}입니다.</p>

</React.Fragment>

)

}

function App() {

let score = 123

return (

<p id="result">점수는 {score}입니다.</p>

</>

)

}

루트를 요구하는 이유는 가상 DOM을 부착할 때 하나의 엘리먼트만 부착하여 그 자식들을 통째로 붙이기 위해서이다. 가변 개수의 엘리먼트를 한번에 붙이려면 그들 사이의 종속 관계나 순서 등의 복잡한 문제가 발생할 수 있는데 이 구조를 JSX에서 미리 완성해 오라는 의미이다.

또 컴포넌트별로 루트가 하나이면 전체 트리를 순회하는 방법이 단순해져 변화를 감지하는 속도가 빨라진다. 그래서 랜더링하는 함수는 인수로 리액트 노드'들'을 요구하는게 아니라 리액트 노드 하나를 요구한다. 얼마든지 많은 노드를 가져도 되지만 컴포넌트로 포장하여 재활용하려면 루트는 딱 하나만 있어야 한다.

root.render(reactNode)

사실 HTML도 <html> 단일 루트 구조를 가지며 XML도 마찬가지로 루트 하나를 두고 그 아래에 엘리먼트를 나열하는 식이다. 알고리즘상 단일 루트가 있는게 더 간단하고 의미가 분명하기 때문이다.

단일 루트 표기법

다음은 단일 루트일 때 JSX의 표기법에 대해 연구해 보자. 예를 들어 인사말만 큼직하게 출력하고 싶다면 h2엘리먼트 하나만 있으면 되고 h2 자체가 루트이므로 따로 div로 감쌀 필요도 없다.

function App() {

return <h2>감사합니다.</h2>

}

정상적으로 잘 출력된다. 그러나 형식성을 갖춘답시고 이걸 두 줄로 내려 쓰면 안된다. 태그와 내용을 개행하는 것도 두 줄이 넘으므로 역시 안된다. 다음과 같이 수정한 후 다시 실행해 보자.

function App() {

return

<h2>감사합니다.</h2>

}

에러는 발생하지 않지만 화면에 아무 것도 나오지 않는다. 꼭 두 줄로 쓰고 싶다면 괄호를 감싸야 한다. 괄호 내에서는 자유롭게 개행할 수 있으므로 태그와 내용을 개행해도 상관 없다. 다음 두 코드는 가능하다.

return (

<h2>감사합니다.</h2>

)

return (

<h2>

감사합니다.

</h2>

)

return 다음에 개행을 해서는 안되는 이유는 JSX의 문제가 아니라 정확하게는 자바스크립트의 자동 세미콜론 삽입(ASI) 문제이다. 두 수의 합을 리턴하는 간단한 자바스크립트 함수로 테스트해 보자. 자바스크립트를 잘 알아도 수시로 문법을 복습할 필요가 있다.

function add(a, b) {

return a + b

}

function add(a, b) {

return

a + b

}

function add(a, b) {

return (

a + b

)

}

가능

불가능

가능

첫 번째 예는 정석적이며 두 번째 예는 개행 때문에 합을 리턴하지 못한다. return문에서 이미 리턴이 결정되었고 뒤에 아무 값도 없으니 여기서 문장이 끝났다고 판단한다. return 다음에 세미콜론이 자동으로 붙으며 undefined를 리턴하는데 이는 원래 목적인 합이 아니다. 에러는 발생하지 않지만 이 함수를 호출해도 합을 얻을 수는 없다.

이렇게 동작할 수밖에 없는 근본적인 이유는 함수 선언부에 리턴타입이 명시되지 않아 뭘 리턴할지 미리 알 수 없기 때문이다. 사실 자바스크립트의 함수는 리턴타입이 무조건 있으며 리턴하지 않을 경우는 undefined를 리턴하는 것으로 되어 있다. return문을 만나면 뒤쪽 값을 리턴하되 값 없이 개행되어 있으면 다음 줄을 읽지도 않고 undefined로 오해해 버리는 것이다.

게다가 세미콜론도 강제 사항이 아니다 보니 개행을 문장의 끝으로 생각할 수밖에 없다. 이런 오해를 방지하기 위해 리턴값을 여러 줄로 적을 때는 반드시 괄호를 열어 놓고 다음줄에 리턴값을 적는다. 이러면 닫는 괄호를 만나기 전까지 하나의 명령으로 인식한다. 심지어 다음 구문도 안되는데 이유는 똑같다. 여는 괄호가 return과 같은 줄에 있어야 한다.

return

(

a + b

)

JSX가 엘리먼트 하나만 리턴하는 경우는 거의 없고 설사 있다 하더라도 내용이 그리 간단하지는 않을 것이다. 또 루트도 필요하니 return문의 형식은 다음 포맷이 무난하다. 최소한 5줄은 되어야 한다.

return (

여기에 가상 DOM에 배치할 엘리먼트를 기술한다.

</>

)

return 다음에 ( 괄호부터 열어 놓고, 설사 태그가 하나밖에 없더라도 다음에 확장할 수도 있으니 <> </>로도 감싸 놓는 것이 좋다. 권장되는 형식대로 쓰면 별 문제없지만 최소한 왜 저런 구문을 쓰고 다른 변형은 안되는지 이해하고 있어야 한다.

자바스크립트는 형식에 구애없이 쓸 수있는 프리포맷(free format)을 지원한다. 공백이나 개행, 들여쓰기를 마음대로 해도 된다. 단, return 문 다음의 개행은 의미가 달라지므로 안된다. 이래서 자바스크립트는 형식성이 떨어진다는 소문이 있는데 부정할 수 없는 사실이다.

자바스크립트보다 타입을 더 엄격하게 취급하는 타입스크립트도 이 문제는 해결하지 못한다. 근본적으로 함수가 뭘 리턴하는지 미리 알 수 없기 때문이다. 그러나 return의 아랫줄이 실행될 수 없음은 인식하며 경고를 보여 준다.

아무 잔소리도 하지 않는 자바스크립트보다는 확실히 더 낫다. 별거 아니지만 초보 시절에 당해보면 황당할 수 있으니 언어의 특성을 잘 알아 두자.

엄격한 문법

HTML 초창기에는 작성자가 실수를 해도 브라우저가 대충 봐 주는 경우가 많았다. 시작과 끝 태그의 짝이 안 맞아도, 속성값을 따옴표로 감싸지 않아도, 심지어 태그끼리 포함 관계가 어긋나도 의도를 유추하여 문서를 보여 주었다. 그러나 규모가 점점 커지면서 방만한 문법은 웹 발전에 걸림돌이 되었고 HTML5 표준 작성시 두 그룹이 첨예하게 대립했다.

▶W3C : 문법을 XML 수준으로 정교하고 엄격하게 제한한 XHTML을 제시

▶WHATWG : 호환성을 최대한 지키는 수준에서 기능을 확장, 정리한 HTML5 제시

결국 시장은 엄격한 문법보다 호환성에 무게를 둔 HTML5를 선택했다. 너무 엄격하면 기존 개발자가 적응하기 어렵고 이전 문서와의 호환 유지도 어렵다. 그러다 보니 현재도 HTML은 유연한 편이며 대충 작성해도 잘 돌아간다. 그러나 HTML도 호환성의 압박으로 어쩔 수 없이 허용하는 것일 뿐 가급적이면 XHTML의 엄격한 문법을 지키는 것이 좋다.

JSX 같은 정교한 구문은 HTML의 물렁한 문법과 맞지 않고 파서가 웹브라우저 수준의 관용까지 허용하기 어렵다. 과연 어떤 차이가 있는지 study 프로젝트내의 성적표 소스를 수정해 보며 연구해 보자. index.html의 div root를 다음과 같이 수정한다.

DIV 여는 태그를 대문자로 쓰고 닫는 태그는 소문자로 썼고 id의 속성값인 root를 따옴표로 감싸지 않았다. 이 상태에서 소스를 저장해도 아무 이상없이 잘 실행된다. 이 영역은 HTML이며 이렇게 엉망으로 써도 문제 삼지 않는다. 그러나 JSX 구문은 호락호락하지 않다. App의 성적표를 다음과 같이 수정하면 에러가 우수수 발생한다. HTML에서는 문제 삼지 않지만 JSX에서는 허용되지 않는다.

function App() {

let score = 123

return (

<DIV>

<p id=result>점수는 {score}입니다.

</div>

)

}

DIV 여는 태그를 대문자로 쓰면 안되며 소문자로 써야 한다. 닫는 태그도 대문자로 써 짝을 맞춰도 안되고 Div도 안된다. <div></div>로만 써야 한다. id 속성값 result는 반드시 따옴표로 감싸야 한다. <p id='result'> 식으로 작은 따옴표를 쓰는 것은 허용한다. <p> 태그의 닫는 태그가 없어도 매정하게 에러이다.

JSX는 XML 문서이고 규칙이 엄격해 정확하게 작성해야 한다. 대부분은 HTML과 유사하게 작성할 수 있지만 몇 가지 주의할 것이 있다. 기존 HTML 개발자가 주로 실수하는 부분을 정리해 보자.

먼저 여는 태그와 닫는 태그는 반드시 짝을 이루어야 한다. 태그란 열고 닫는게 원칙이지만 HTML은 편의상 여는 태그만 두는 것도 허용한다. 대표적인 예가 목록을 나열하는 <li>인데 대부분의 항목이 한줄로 끝나 </li>가 굳이 없어도 된다. 그러나 JSX에서는 안된다. 성적표 아래에 과목별 점수를 목록으로 적어 보자.

function App() {

let score = 123

return (

<p id="result">점수는 {score}입니다.</p>

<ul>

<li> 국어 : 80

<li> 영어 : 43

</ul>

</>

)

}

HTML에서는 적법하고 당연히 잘 나오는 문서이다. 그러나 JSX에서는 <li>의 닫는 태그가 없어 어디까지가 끝인지 애매하며 여러 줄로 기술할 때는 끝을 찾기 어려워 에러 처리해 버린다. 반드시 </li>로 닫아야 한다.

홀로 쓰는 태그도 꼭 닫아야 한다. 만약 닫는 태그를 꼭 생략하고 싶다면 여는 태그의 끝을 />로 적는다. 성적표 아래에 이미지 하나를 더 출력해 보자. img 태그로 이미지의 주소를 적으면 된다.

function App() {

let score = 123

return (

<p id="result">점수는 {score}입니다.</p>

</>

)

}

그러나 다음은 안된다. HTML에서는 흔하게 사용하는 구문이지만 JSX에서는 홀태그의 끝을 열린 채로 방치하면 끝을 찾지 못해 에러다.

아니면 <img src=~></img> 형식으로 끝 태그를 달아 줘야 한다. 문단 중간에 개행할 때 HTML은 보통 <br>태그를 끼워 넣지만 JSX에서는 <br></br>로 열고 닫는 태그의 짝을 맞춰야 한다. <br />로 쓰는게 제일 간편하다.

3-3.JSX 실습

코드 내장

JSX는 외형적으로 HTML과 유사하지만 자바스크립트 코드를 포함하기도 한다. 이때는 일반 문자열과 구분하기 위해 { } 괄호로 코드를 감싸는데 예제에서 이미 score 변수를 문자열 사이에 넣어 보았다.

점수는 {score}입니다.

이 문자열을 해석할 때 { } 괄호안의 식을 평가하여 실제값을 써 넣는다. score가 123으로 초기화된 변수이므로 {score} 자리에 123이 들어간다. { } 괄호가 없으면 score는 변수가 아니라 그냥 문자열이며 "점수는 score입니다."로 출력된다.

정수가 아닌 문자열도 가능하다. { }로 감싸면 정수든 문자열이든 변수의 값을 평가하여 문자열 사이에 넣어 준다. 변수임을 강조하기 위해 let으로 선언했는데 const로 정의한 상수도 물론 가능하다.

function App() {

let name = "홍길동"

let score = 123

return (

<div>

<p id="result">{name} 학생의 점수는 {score}입니다.</p>

</div>

)

}

그러나 { } 괄호안에 객체를 넣는 것은 안된다. 가능하게 만들 수도 있지만 어떤 멤버가 출력 대상이고 각 멤버를 어떻게 랜더링할지 애매하므로 개발자가 직접 멤버별로 출력하도록 되어 있다. 다음 예제는 잘 실행된다.

function App() {

let student = {

name : "홍길동",

score : 123

}

return (

<div>

<p id="result">{student.name} 학생의 점수는 {student.score}입니다.</p>

</div>

)

}

{ } 안의 자바스크립트 코드는 하나의 값을 리턴하는 표현식(expression)만 넣을 수 있다. 변수는 그 자체가 값이므로 당연히 표현식이며 함수 호출문이나 복잡한 연산문의 결과도 표현식이므로 가능하다. 다음 문장은 모두 허용된다.

<p id="result">점수는 {score + 100}입니다.</p>

<p id="result">점수는 {score > 100 ? "합격":"불합격"}입니다.</p>

score + 100 연산식은 덧셈 결과를 리턴하는 표현식이다. 삼항 조건 연산문도 둘 중 하나를 리턴하므로 { } 괄호안에 쓸 수 있다. Math.PI는 상수이고 add 함수의 호출 결과도 하나의 값이다. 그러나 어떤 동작을 처리하는 명령(Statement)은 작성할 수 없다. 다음 문장은 모두 에러이다.

<p id="result">점수는 {return score}입니다.</p>

<p id="result">점수는 {if (score > 100) console.log('합격')}입니다.</p>

return score는 score를 리턴하라는 명령이며 실행 결과는 값이지만 이 문장 자체는 값이 아니다. if 문으로 값을 평가할 수는 있지만 console.log로 메시지를 출력하는 동작도 명령일 뿐 값이 아니므로 쓸 수 없다. { } 안에서 함수를 호출하는 것은 가능하다.

function App() {

function calcScore() { return 123 }

return (

<div>

<p id="result">점수는 {calcScore()}입니다.</p>

</div>

)

}

이때도 똑같은 원칙이 적용되는데 함수가 정수나 문자열을 리턴하여 값으로 평가되어야 한다. 객체를 리턴하면 안된다.

스타일 지정

태그의 속성값은 문자열이므로 대부분의 속성을 그대로 다 표현할 수 있다. 앞에서 <img> 태그의 src 속성을 HTML과 같은 방식으로 이미 사용해 봤다. 그러나 style 속성은 복잡해서 문자열로 직접 지정하는 것을 허락하지 않는다. 다음 문장은 HTML에서는 적법하지만 JSX에서는 동작하지 않는다.

이 구문을 지원하려면 가능은 하겠지만 트랜스파일러가 CSS 구문까지 정확히 파악하는 것은 무리인데다 인라인 스타일 자체를 권장하지 않는다. 정 스타일을 인라인으로 직접 지정하려면 속성과 값의 쌍을 객체로 정의하여 지정한다. 다음 코드는 제목을 파란색의 40픽셀로 크게 출력한다.

function App() {

let score = 123;

const h2style = {

fontSize:40,

color:'blue'

}

return (

<p id="result">점수는 {score}입니다.</p>

</>

)

}

h2style 객체 안에 폰트크기와 색상을 지정하고 h2 태그의 style 속성이 이 객체를 지정했다.

객체를 따로 정의하는게 귀찮으면 객체 리터럴을 속성에 인라인으로 집어 넣을 수 있다. 다음 구문은 가능하며 효과도 같다. 객체 리터럴을 바로 적어 주는거라 h2style 객체명을 지정할 필요 없다.

function App() {

let score = 123;

return (

<p id="result">점수는 {score}입니다.</p>

</>

)

}

이 구문은 주의해서 볼게 많다. style 속성값에 {} 괄호를 이중으로 썼는데 안쪽과 바깥쪽 괄호의 의미가 다르다. 자바스크립트에서 객체 리터럴은 { } 괄호로 감싼다. 그리고 JSX가 자바스크립트 코드를 감쌀 때도 { } 괄호를 사용한다. 그래서 괄호가 두 개다.

안쪽, 바깥쪽 괄호의 역할이 달라 둘 다 필요하다. 리액트에서는 이런 식으로 괄호가 중첩되는 경우가 흔한데 }])} 식으로 4중, 5중으로 중첩되기도 한다. 규칙을 잘 알아 둬야 헷갈리지 않는다.

이 코드에서 또 주의해서 볼 부분은 fontSize인데 CSS에서 이 속성의 원래 이름은 font-size이지만 자바스크립트는 명칭 중간에 -가 올 수 없다. 그래서 -를 빼고 캐멀케이스로 각 단어의 첫 글자를 대문자로 바꿔 fontSize로 표기한다. line-height, text-indent 등의 속성명도 lineHeight, textIndent로 적는다.

만약 정 CSS 스타일로 속성명을 사용하려면 따옴표로 감싸 'font-size'로 적으면 된다. 크기값은 단위를 생략하면 px를 기본 적용하되 다른 단위를 붙이려면 이것도 따옴표로 감싸야 한다. 다음 스타일은 폰트 크기를 40pt로 지정한다.

40pt라고 적는게 왜 안되는지는 자바스크립트에서 이런 명칭으로 변수나 상수를 정의할 수 없음을 생각해 보면 된다. HTML, CSS에서 가능했던 명칭 중 코드에서 쓰기에 부적합할 거 같은 명칭은 따옴표로 감싼다.

리액트에서 스타일을 지정하는 정석은 css 파일에 스타일을 쓰고 임포트하는 것이다. 인라인으로 객체를 지정하는 방식도 가능은 하지만 내용과 표현의 분리 원칙에 맞지 않고 분업에도 불리하다. App.css에 다음 스타일을 추가한다. <p>의 id인 result에도 눈에 잘 띄게 노란색 배경 스타일을 지정해 보자.

....

.head {

font-size:40px;

color:blue;

}

#result {

background:yellow;

font-size:20px;

}

CSS 파일 안에서는 CSS의 문법대로 작성한다. App.tsx에서는 스타일을 임포트하여 적용한다. 배포 예제 선두에는 import문이 미리 작성되어 있다. 당연한 얘기지만 두 파일을 같이 편집할 때는 모두 저장해야 효과가 나타난다. 여러 개의 파일을 편집했을 때는 파일/모두 저장 명령을 사용하는게 빠르다.

이렇게 작성해 놓으면 번들러가 스타일 시트의 스타일을 객체로 바꿔 JSX 엘리먼트에 적용해 준다. App.css에 지정한 스타일은 전역적으로 반영되므로 통합 배포 파일의 다른 예제에도 영향을 미친다. 결과를 확인한 후에는 주석으로 막아 두자.

명칭 충돌

지금까지의 예에서 봤다시피 JSX는 독특하다. HTML과 비슷하면서도 { }안에 스크립트 코드를 가지기도 하고 style 속성에 CSS 구문이 들어가기도 한다. 세 언어를 짬뽕하다 보니 불가피하게 명칭충돌이 발생할 수 밖에 없다. 키워드 목록도 다르고 명칭 규칙도 제각각이기 때문에 고유한 제약을 추가할 수밖에 없다.

앞 실습해서 App.css에 head 클래스와 result ID에 스타일을 지정했는데 CSS 파일은 원래 스타일시트를 작성하는 곳이므로 backGround나 fontSize로 적으면 안되고 CSS의 속성명을 그냥 적어야 한다. 그런데 의외의 곳에서 이상한 점이 있다. 태그의 class 속성을 지정하는 속성명이 className인데 이렇게 되어 있는 사정은 복잡하다.

HTML에서 class는 속성의 이름이지만 자바스크립트에서는 클래스를 정의하는 키워드이다. JSX는 이 둘을 합친 것이다 보니 명칭 충돌이 발생한다. 그냥 class라고 적으면 속성의 이름을 의미하는 것인지 클래스를 정의하는 키워드인지 모호하다. 그래서 JSX에서는 태그의 클래스명을 지정할 때 className이라는 별도의 속성명을 사용한다.

그렇다면 이 상태에서 속성명을 그냥 class로 바꾸면 어떻게 될까? V16 이전에는 매정하게 에러 처리했지만 그 이후에는 문맥을 파악하여 경고로 처리하도록 완화했다. 저장 후 새로 읽어보면 콘솔에 다음 경고가 발생하지만 실행은 정상적으로 되며 스타일도 잘 적용된다.

Warning: Invalid DOM property `class`. Did you mean `className`? at h2 at App

철자는 같지만 h2 태그에 들어 있는 class는 속성명임을 추론할 수 있어 당장은 큰 문제가 없다. 그러나 어떤 경우는 이런 추론이 틀릴 수도 있고 장래에 미묘한 문제를 일으킬지 장담할 수 없다. 문맥상 구분은 가능하지만 명확하지 않고 사람이 보기에도 헷갈린다.

그래서 리액트는 미래에 어떤 말썽을 일으킬지 알 수 없는 명칭에 대해 별도의 다른 명칭을 사용할 것을 권장한다. 그래서 className이라는 별도의 속성명을 따로 정의한 것이다. 대소문자도 엄격하게 구분하므로 classname이나 ClassName으로 적으면 안된다.

class 외에 <label> 태그의 단축키를 지정하는 for 속성도 자바스크립트의 반복문인 for와 철자가 같아 htmlFor를 대신 사용한다. 반면 아래쪽 p 태그에 붙인 id="result" 속성은 그냥 써도 된다. id는 자바스크립트의 예약어가 아니기 때문이다.

철자가 같은 속성은 대소문자 구성에 유의해야 한다. HTML은 아무렇게나 적어도 되지만 JSX에서는 maxLength, tabIndex, colSpan, rowSpan 등 두 단어로 된 속성은 모두 캐멀캐이스로 정확하게 적어야 한다.

이벤트 연결

JSX에 정의한 태그의 이벤트 핸들러를 지정하는 방법은 자바스크립트와 비슷하다. 태그의 이벤트 속성에 핸들러 함수를 지정한다. 보통 <button>이나 <input> 같은 UI 태그에 이벤트를 연결한다. HTML 태그는 DOM 요소이므로 표준 이벤트가 존재하고 브라우저가 이벤트를 검출해준다.

그러나 우리가 직접 만든 리액트 컴포넌트는 모양이나 기능이 천차만별이고 브라우저가 직접 관리하는 DOM 요소가 아니라 이벤트를 연결할 수 없다. 컴포넌트안에 있는 DOM 요소에 이벤트를 연결해야 한다. 즉 <App> 컴포넌트 자체에는 이벤트를 지정할 수 없고 그 안에 있는 <h2>나 <p>에 이벤트를 연결한다. 다음 예제는 h2를 클릭할 때 메시지 박스를 연다.

function headerClick() {

alert("클릭했습니다.");

}

function App() {

let score = 123;

return (

<p >점수는 {score}입니다.</p>

</>

)

}

대화상자를 여는 headerClick 함수를 정의하고 h2의 onClick 이벤트에 이 함수를 지정했다. 이벤트 이름이 onclick이 아니라 onClick이라는 점을 유의하자. 변수값을 참조할 때와 마찬가지로 함수를 참조할 때도 {headerClick} 형식으로 { } 괄호로 감싼다. 실행 후 h2을 클릭하면 대화상자가 열린다.

핸들러가 별도의 함수임을 보이기 위해 headerClick 함수를 App 컴포넌트 바깥에 작성했는데 안쪽으로 넣어도 상관 없다. 자바스크립트는 함수안에 지역함수를 정의하는 것을 허용한다. 컴포넌트가 모든 것을 포함하면 재활용이 쉽다는 이점이 있어 핸들러는 가급적 안에 작성하는 것이 바람직하다.

function App() {

let score = 123;

function headerClick() {

alert("클릭했습니다.");

}

return (

<p >점수는 {score}입니다.</p>

</>

)

}

JSX의 이벤트 속성은 리스너 방식으로 동작한다. 자바스크립트는 인라인 모델을 지원하여 함수 호출문을 적거나 직접 코드를 작성할 수도 있지만 JSX에서는 함수의 참조를 대입하는 방식만 지원한다. 다음 코드는 이벤트 핸들러를 지정하는 것과는 다르다.

JSX의 { }내의 코드는 평가를 위해 즉시 실행한다. 이렇게 적으면 랜더링할 때 함수가 호출되어 버리므로 클릭과 상관없이 대화상자가 열려 버린다. 이벤트 처리 코드를 문자열 형식의 인라인으로 직접 작성하는 것도 안된다. 브라우저는 문자열내의 자바스크립트 코드를 읽어 직접 실행해 주지만 JSX는 이벤트와 함수를 연결해줄 뿐이다.

이벤트 처리 구문이 짧을 때는 별도의 함수로 정의하는게 귀찮기도 하고 재사용의 의미도 없다. 이럴 때는 인라인으로 함수를 작성하되 함수 리터럴도 값이므로 { } 괄호안에 넣는다. 다음 코드는 잘 동작한다.

function App() {

let score = 123;

return (

<p >점수는 {score}입니다.</p>

</>

)

}

function키워드로 함수 리터럴을 이벤트 핸들러를 작성했다. 뒤쪽에 괄호가 )}}>로 4개나 겹쳐 있는데 각각이 어떤 역할인지 잘 구분해야 한다. 함수 리터럴의 본체를 {}로 감싸야 하고 이걸 JSX안에 넣어야 하니 바깥에 {}도 필요하다. 리액트에서는 함수 리터럴보다는 화살표 함수를 더 많이 쓴다.

<h2 onClick={() => alert('클릭했을걸요')}>성적표</h2>

문법적 특성이 약간 다르며 얼마 차이 나지 않지만 더 짧게 쓸 수 있다. 이런 경우에는 간편하게 쓸 수 있지만 화살표 함수끼리 중첩될 때는 조금 헷갈리는 면이 있다.

주석

주석은 코드를 유지 관리하기 위해 꼭 필요하다. HTML에는 최소 3가지 언어가 섞여 있으며 여기에 JSX까지 더해졌다. 각 언어마다 표준 주석은 제각각이다. 난잡한 지경이지만 만든 주체가 다르다 보니 어쩔 수 없는 상황이다.

언어	주석
HTML	<!-- -->
자바스크립트	한줄 // 여러줄 /* */
CSS	/* */
JSX	{/* */}

주석간의 관계가 복잡한데 자바스크립트나 CSS는 HTML 주석 지정을 완전히 무시한다. 즉 로 감싼다고 해서 없는 문장이 아니다. 왜 이렇게 되어 있는가 하면 과거 브라우저 호환성이 좋지 않을 때 스크립트나 CSS를 로 감싸 지원하지 않는 브라우저에서는 무시하도록 하는 정책을 썼기 때문이다.

이후 자바스크립트에서도 HTML 주석을 허용하는 브라우저가 있었지만 원칙적으로 허용하지 않는다. JSX가 HTML과 유사한 형태여서 주석을 HTML 형식으로 달 수 있을 거 같지만 안된다. 아예 다른 언어이기 때문에 주석도 당연히 다르다. 다음 코드는 에러이다.

function App() {

let score = 123;

return (

<p id="result">점수는 {score}입니다.</p>

</>

)

}

<> 괄호 안에 들어 있으니 태그로 인식할려고 시도하는데 !--이라는 태그가 없으니 에러이며 화면에 아무 것도 나오지 않는다. 그럼 JSX에서 자바스크립트의 주석은 어떨까?

function App() {

let score = 123;

return (

// 이것은 주석이다.

<p id="result">점수는 {score}입니다.</p>

</>

)

}

이 문장은 에러는 발생하지 않지만 주석이 웹 브라우저에 그대로 나타나 버린다. 태그가 아닌 것은 문자열로 해석하니 주석조차도 웹페이지의 일부가 되어 버린다.

여러 줄 주석인 /* */ 도 마찬가지로 JSX에서는 쓸 수 없다. 이 얘기를 다르게 해석하면 JSX 바깥일 때는 쓸 수도 있다는 뜻이다. 다음 문장은 모든 주석이 합법적이다.

function App() {

let score = 123;

/* 여기는 JSX 바깥이라 쓸 수 있다. */

return (

// 여기도 아직 JSX 구문 시작전이다.

{/* 이것은 주석이다. */}

<p id="result">점수는 {score}입니다.</p>

</>

)

}

트랜스파일러가 번역하는 JSX의 범위가 어디부터인가를 잘 생각해 보면 쉽게 구분할 수 있다. 루트인 <> ~ </>까지가 JSX 구문이다. JSX 안에서 정 주석을 쓰고 싶으면 고유의 주석 표기법인 {/* */} 괄호를 사용한다. JSX 안에서 자바 스크립트 코드를 { }로 감싸도록 되어 있으니 /* */도 { }로 감싸면 된다. 아쉽게도 한줄 주석은 없다.

JSX 구문 바깥, 예를들어 <> 태그 앞이나 return문 앞에는 이 주석을 쓸 수 없다. 코드의 어디쯤인가에 따라 사용해야 할 주석이 제각각이다. 이건 JSX의 문제가 아니라 이전에도 HTML, CSS, 자바스크립트의 주석이 다 달랐었다. 언어를 조합해서 쓰다 보니 헷갈릴 수밖에 없다.

JSX의 기본 문법에 대해 알아 봤는데 더 복잡한 규칙도 있다. HTML, CSS와 자바스크립트, 게다가 JSX까지 여러 언어가 뒤섞여 있는 형태이다보니 규칙이 까다로울 수밖에 없다. 그러나 잘 생각해 보면 다 합리적인 이유가 있고 납득할만한 규칙이다.

HTML 문서를 잘 작성하던 사람도 새로운 규칙에 익숙해지는데는 시간이 걸리며 당분간은 시행착오를 겪어야 할 것이다. 이런 사람을 위해 온라인 변환기를 제공한다. 왼쪽에 HTML 문서를 작성하면 JSX 구문으로 실시간 번역해 준다.

https://transform.tools/html-to-jsx

뭐가 뭔지 하나도 모르겠다면 HTML과 CSS, 자바스크립트 문법이 탄탄하지 않아서일 확률이 높다. 저기서는 되지만 여기서는 안된다를 이해해야 하는데 저기에서 원래 어땠는지를 모르니 더 헷갈리는 것이다. 이 참에 관련 부분을 찾아 복습하고 오자. 여기서 갈팡질팡하면 리액트 연구를 원활히 진행하기 어렵다.