brunch

You can make anything
by writing

C.S.Lewis

by 디디디 Dec 23. 2024

React.js로 스타벅스 스페셜 메뉴 사이트 만들기

개발하는 디자이너 챌린지 - 03

챌린지 소개

'개발하는 디자인 챌린지'는 스레드(threads)에서 모집한 10명의 디자이너 참가자들과 개발 스터디. 실습을 진행하기 위해 매주 1회 발행하는 교육자료로 쓰이는 글입니다. 이 챌린지는 자세한 문법을 처음부터 알려주는 방식이 아닌 디자인-개발 플로우의 연관성 및 기본 개념을 알려주고 과감히 바로 예제부터 시작하는 튜터링 방식을 취하고 있습니다.


0. 프롤로그

두 번째 에피소드에서는 react.js가 웹 서비스 개발 프로세스 전반에 미친 영향을 간략한 역사와 함께 알아보았습니다. 그리고 v0라는 툴을 통해 간단한 예제를 만들어보고 1,2화의 내용을 참고하여 각자 코드를 리뷰해 보는 과제를 냈었습니다.


세 번째 에피소드에서는 참가자분들의 과제 중 한 개를 골라 제가 좀 더 다듬어 보고, 이 예제를 통해 react.js의 기본적인 문법을 더 다듬어보는 시간을 갖아보겠습니다.


1. 스타벅스 스페셜 메뉴 웹사이트 만들기


일단 지난 에피소드(React.js가 디자이너에게 의미하는바)에서 v0에서 작성한 프롬프트를 통해서 대략적인 웹사이트의 구조가 생성되는 것을 확인했습니다. 저는 이 링크와 프롬프트를 참고해서 각자 원하는 주제의 웹사이트 초안을 작성해 오는 과제를 냈었습니다.



참가자분들은 대부분 개발 지식이 없었기 때문에 일단 제가 드린 PRD를 응용해서 프롬프트를 입력하는 방식으로 진행하였으며, 결과물은 몇 가지 이유에서 완벽하지 않습니다.


일단 현재 수준의 V0와 비개발자의 소통만으로 완벽한 UI를 만들기 제한됩니다.

두 번째로 실제 필요한 이미지를 웹상에서 찾아서 직접 url을 입력해야 합니다.

마지막으로 V0이 임의로 설치한 패키지(외부 라이브러리)가 제대로 작동하지 않을 리스크가 있습니다.


다만 V0은 각자 로컬 환경에서 개발환경 세팅을 하지 않고 바로 실습을 할 수 있다는 장점이 있고, 제가 참가자분들의 코드를 보고 이어서 수정할 수 있다는 장점이 있어서 이러한 실습 방식을 선택했습니다. 그중 가장 마음에 들었던 스타벅스 지역별 스페셜 메뉴 사이트를 이어서 제가 완성시켜 보기로 했습니다.


아래 그림은 참가자분이 처음 입력한 프롬프트로 생성된 첫 화면입니다.

일단 고칠 구석이 많지만 와이아프레임 수준의 웹사이트가 만들어졌고 크게 3가지 섹션으로 구성됩니다.


첫 번째는 세계 지도에 스페셜 메뉴를 파는 지역을 표시하는 맵 섹션

두 번째는 모든 메뉴를 한 번에 볼 수 있는 메뉴 섹션

세 번째는 메뉴의 테이스팅 노트를 기준 어떤 메뉴가 있는지 볼 수 있는 테이스팅 노트 섹션입니다.


역시 맵의 마커를 비롯한 기타 이미지는 깨진 상태이며, 메뉴도 3개밖에 없어 내용적으로 완성되지 않은 모습입니다.


 

2. 웹 사이트 수정 과정

일단 자세한 코드 리뷰를 하기 전에 제가 웹사이트를 수정한 과정을 간략하게 설명해 드리겠습니다. 이 부분은 자세히 모르셔도 됩니다. 제가 이해하기 쉬운 실제 웹사이트처럼 만들기 위한 과정정도로 이해하시면 됩니다.


2-0 MUI 활용

일단 모든 컴포넌트를 google의 MUI 라이브러리로 바꿨습니다. 이유는 어떠한 라이브러리를 지정하지 않으면 v0가 다양하 방식으로 컴포넌트들의 스타일과 작동방식을 구현할 텐데 이렇게 생성된 코드는 학습용으로 좋지 않습니다.


하지만 MUI를 활용할 경우 라이브러리에서 미리 준비된 컴포넌트들의 props와 style을 수정하는 방식으로 사용함으로써 학습 범위를 한정시킬 수 있습니다. 이번 예제에서는 굳이 MUI를 컴포넌트를 커스텀하는 방식을 모르셔도 됩니다. 다만 라이브러리에 이런 컴포넌트와 소성들이 있구나 정도만 넘어가시고 다음 화에서 더 자세히 다루려 합니다.


2-1 충분한 Data 확보

일단 v0가 처음 생성한 데이터 샘플이 너무 작아서 chat GPT로 동일한 포맷의 데이터를 추가해 달라고 했습니다. 여기까지는 원활하게 진행되지만 문제는 실제 스타벅스 메뉴 이미지를 찾기에는 무리가 있습니다.


그래서 일단 스타벅스 공식 웹사이트에서 메뉴 사진을 하나 갖고 와서 사용했습니다. 아직까지는 모든 메뉴에 동일한 이미지가 적용된 상태입니다.



2-2 맵 수정

그리고 v0가 처음 만든 웹사이트의 상단 map은 2가지 이상한 점이 있습니다. 일단 마커에 잘못된 이미지 url을 불러왔고, 맵의 척도가 무한대로 작아지기 때문에 어느 시점부터 빈 회색 공간(실제 존재하지 않는 공간)이 보입니다. 이 두 가지 영역을 프롬프트로 통해 수정 습니다.


다만 여기에는 leaft라는 오픈 소스를 사용했는데 당장에 외부 라이브러리를 커스텀하는 부분은 어려울 수 있으니 이 영역은 다음화에서 자세히 설명드리겠습니다.

위 변경 사항으로 맵이 이 이하로 축소되지 않고 마커도 직접 SVG로 그린 이미지로 교체되었습니다.


2-3 기타 UI 수정

추가로 메뉴를 보여주는 Card UI에 타이포그래피를 정돈하고 해당 국가 이미지를 추가하였습니다. 다행히 국기를 추가하는 과정은 국가 코드만 기입하면 해당 국기 이미지를 보여주는 웹사이트가 있어서 원활하게 작업할 수 있었습니다.


그리고 마지막 테이스팅 노트 섹션은 노트 chip을 클릭하면 메뉴의 Card UI를 수정한 리스트들의 모달이 뜨는 방식으로 수정했습니다.




3. 코드 리뷰하기

위의 과정을 거쳐서 기본적인 오류만 수정한 웹사이트의 모습은 아래와 같습니다. v0 링크 아래는 편의상 제가 코드 이미지를 첨부하였지만 반스디 v0링크와 비교하면서 내용을 보실 것을 권장합니다.

아직 각 메뉴별 이미지를 교체하는 작업과 메뉴 리스트가 너무 많아서 대륙별로 정돈하면 좋겠지만 일단 지금 상태에서 코드 리뷰와 react.js의 문법을 설명해 보겠습니다. 리뷰는 크게 프로젝트 구성, React 컴포넌트 작성법, props, state 들여다보기로 나눴습니다.


3-1. 프로젝트 구성

아래 화면을 보시면 App.js라는 파일이 열려있습니다. App은 모든 react.js의 root 컴포넌트에 해당합니다. 말 그래도 가장 먼저 시작되는 컴포넌트라는 점이죠. 앞선 에피소드에서 Ajax를 언급했듯이 react.js, angular, vue 등 모든 모던 프레임워크는 SPA (single page appliaction)의 형태를 띠고 있습니다. 즉 한번 물리적인 App이 실행되면 페이지가 바뀌지 않는다는 뜻이죠.


이 시작을 하는 것이 App이며 모든 컴포넌트들은 App 컴포넌트가 둘러싸게 됩니다. 지금 예제는 one page라서 필요가 없지만 사용자 입장에서 페이지가 바뀌려면 물리적인 url이 아닌 router를 바꾸어야 하는데 이 개념은 이후 에피소드에서 다루겠습니다. 어쨌든 모든 react.js 웹사이트는 App.js에서 시작한다는 점을 명심하세요.


App.js 안의 코드를 다시 자세히 보시면 가장 밖에서부터 어떤 태그들에 의해 둘러 쌓여있습니다.


ThemeProvider - MUI의 스타일을 담당하는 theme파일을 모든 컴포넌트가 사용할 수 있도록 제공해 주는 역할을 합니다. 지금은 넘어가도 됩니다.

CaseBaseline - 위와 비슷한 역할을 하며 이것도 지금은 넘어가셔도 됩니다.

Container - MUI 컴포넌트로 말 그대로 무언가를 담을 수 있는 기본적인 컨테이너입니다.

Box - Container와 비슷하지만 더 작은 컴포넌트들을 감 쌓을 때 사용됩니다.

Typography -  본문, 헤드라인, 캡션 등 타이포그래피를 위한 컴포넌트입니다.

위 컴포넌트들의 역할과 사용방법은 MUI 공식 문서에서 쉽게 찾아볼 수 있습니다.


그리고 가장 중요한 건 그 안에 MapSection, MenuListSeciton, TastingNoteSection이 있습니다. 이 웹사이트의 가장 핵심적인 요소로 왼쪽 File 사이드바의 sections 폴더에 해당하는 파일이 있는 것을 볼 수 있습니다.


누군가 App.js파일을 봤을 때 이 웹사이트가 '무엇'을 하는지 한 번에 알기 쉽도록 해야 합니다. 이것이 이전 에피소드에서 얘기했던 React.js의 선언적 프로그래밍의 특징입니다. 이 웹사이트가 스타벅스에 스페셜 메뉴에 관한 것이라 점을 전제로 했을 때 첫뻔째 섹션에서는 지도에 지역을 보여주겠구나, 두 번째 섹션에서는 모든 메뉴를 보여주겠구나, 세 번째는 테이스팅 노트에 관해서 다루겠구나 등을 유추할 수 있어야 합니다.



그리고 코드 최상단에 import는 컴포넌트 작성에 필요한 외부 요소들을 갖고 올 때 사용합니다. @Mui로 시작하는 것은 mui라이브러리에서 필요한 컴포넌트 및 함수들을 갖고 올 때 사용하고, 그 나머지 './'로 시작하는 것은 같은 프로젝트에 있는 파일들을 불러올 때 사용합니다. 여기서 주목할 점은 위에 App.js에 있는 모든 컴포넌트가 starbucksMenus 데이터를 props로 사용하고 있다는 점입니다.


결국 선언적인 프로그래밍과 이를 사용하는 데이터의 구조를 통해 이 웹사이트가 무엇을 하는 웹사이트인지 개괄적으로 먼저 파악하는 게 중요합니다. 데이터를 들여다보겠습니다.


먼저 데이터가 정의된 시작점에서 export const starbucks = [....]로 시작하는 것을 알 수 있습니다. 이 데이터 파일을 예시로 기본적으로 javascript의 문법을 설명하겠습니다.


export - 사용하면 이 변수를 외부에서 사용하겠다는 선언입니다.

const -  상수라는 뜻의 constant의 약자입니다. const의 특징은 상수라는 뜻대로 변경할 수 없습니다.

starbucksMenu - 는 const 뒤에 내 맘대로 정할 수 있는 변수 명입니다. 보통 이렇게 첫 단어를 소문자로 하고 두 번째 이상 단어의 첫 글자만 대문자로 바꾸는 방식을 camelCase 방식이라 합니다. 대부분의 변수는 이 규칙을 따라서 만들어야 가독성과 공동작업자와 지켜야 할 규칙을 유지하기 좋습니다. 항상 위 순서대로 작성해야 합니다. 만약 외부 참조가 필요 없다 하면 export를 생략하면 됩니다.


그리고 두 가지 다른 모양의 괄호를 보실 수 있습니다. [ ], {}

[] 배열(Array) - 두 개 이상의 변수를 함께 담을 때 배열을 사용합니다. 배열은 javascript에서 정말 많이 사용합니다. 배열은 인덱싱을 통해서 특정 위치의 데이터에 접근할 수 있습니다. 예를 들어 위의 코드에서  starbucksMenu [0]이라고 하면 마차 벚꽃 프라푸치노에 해당하는 객체를 얻게 됩니다.


{} 객체(Object) - 두 개 이상의 무언가를 담고 있다는 점에서 배열과 비슷합니다. 배열은 순차적인 성격의 아이템을 넣을 때(예를 들면 요일, 일별 방문자수 등등)에 적합하고 객체는 서로 관련이 있는 다른 속성들을 담을 때 적합합니다. 예를 들면 스타벅스 스페셜 메뉴에는 다양한 속성들(이름, 이미지, 재료, 네이스팅 노트)이 있는데 이를 한 개의 객체에 담는 것이 적합합니다. 그런데 다시 보시면 이 객체 안에는 다시 재료테이스팅 노트라는 항목에 배열이 사용된 것을 보실 수 있습니다.


이처럼 배결과 객체는 필요에 따라 언제든지 중첩돼서 사용할 수 있습니다. 일단 위 객체에 포함된 키값을 다 살펴보고 App.js에 불러온 각 섹션들을 보시면 각 섹션에서 이 데이터들이 어떻게 쓰일지 유추해 볼 수 있습니다. 잠시 이 데이터들이 어떻게 흘러가나 차례대로 살펴보겠습니다.


MapSection

일단 위코드가 정확히 무엇인지는 모르겠지만 menus로 받은 props에서 map이라는 함수를 사용하더니 Marker 컴포넌트를 안에서 불러옵니다.


MenuListSection

마찬가지로 메뉴리스트 섹션에서도 menus가 map함수 안에서 menu라는 파라미터를 다시 MenuCard의 props로 넘겨줍니다.

 

TastingNoteSection

마지막으로 tasting note section에서도 allTastingNotes라는 배열이 map함수를 부르더니 각 테이스팅 노트를 표현할 Chip 컴포넌트에 다시 note라는 props를 넘겨줍니다.


여기서 Map이란 array가 기본적으로 갖고 있는 javascript의 함수입니다. map은 배열 안의 모든 항목들에 접근할 때 사용합니다. 일단 모든 코드가 { } 괄호에 감싸져 있는 이유는 앞선 에피소드에서 설명한 jsx의 문법 중 하나로 html의 태그나 컴포넌트 사이에서 array를 컴포넌트에 바인딩하기 위해서 스크립트를 사용할 때는 { } 괄호를 열어주어야 합니다. 즉 태그 사이에 코드가 존재한다는 뜻입니다.


그리고 map() 함수 안에는 다시 (item) => (<Component props={item} />) 식의 코드가 들어가는데 map 함수 안에 들어가는 또 다른 함수는 array의 각 항목이 반복해야 할 행동을 뜻합니다. 이때 이름은 그 어떤 것으로 해도 상관없지만 상황을 고려해서 알맞은 이름을 붙여주는 것이 중요합니다. TastingSection을 예로 들면 모든 노트가 Chip컴포넌트에 반복해서 정보를 제공해 주는 코드라 할 수 있습니다. 즉 저 위의 코드로 모든 테이스팅 노트에 해당되는 Chip을 그리는 거죠.


위 예시는 일단 프로젝트의 데이터 흐름을 살펴보기 위해 들었으므로 작세한 문법은 다음 react 컴포넌트 들여다 보기에서 다루겠습니다.



3-2  react 컴포넌트 들여다 보기

2번째 에피소드에서 초창기 모던 프레임워크 Angular와 React.js를 비교하면서 왜 jsx를 고안하게 되었는지를 설명했습니다. jsx는  React.js의 모든 컴포넌트파일의 기본 확장자이며 javascript와 XML을 같이 사용하겠다는 뜻입니다. 즉 스크립트를 태그 및 컴포넌트와 결합해서 유연하게 사용하겠다는 의미입니다.


이로 인해 위에서 설명한 데이터 흐름처럼 App에서 한 방향으로 내려다 준 data들을 각 커버넌트들이 props로 받아서 동적으로 컴포넌트들을 바인딩(데이터를 컴포넌트에 결합시키는 것)할 수 있는 것입니다.


이제는 jsx에서 각 컴포넌트들이 어떻게 만들어지는지 살펴보겠습니다.


import의 역할

import는 해당 컴포넌트기 필요한 외부 자원들을 불러올 때 사용하며 모든 import는 무조건 파일의 최상단에 있어야 합니다. 아래 MenuListSection의 코드를 보시면 일단 jsx를 사용하기 위해 React 그리고 Grid, Box 컴포넌트들을 mui에서 불러왔습니다.


마지막으로 제가 직접 구성한 SectionTitleContentContaienr 컴포넌트들을 프로젝트의 다른 컴포넌트에서 불러왔습니다.


import 구문이 다 끝났다면 이제 컴포넌트를 선언해야 합니다. 지금의 jsx는 함수형 컴포넌트를 지향합니다. 무슨 예기냐면 jsx의 특징을 이용해서 컴포넌트 자체로 함수처럼 취급하겠다는 것입니다. 함수를 반복하는 연산을 사용하기 위해 미리 정의해 둔 기능 정도로 이해하시면 됩니다.


과거에는 다른 방식으로 처리했지만 지금의 react.js에서는 대부분 이 방식을 사용하는 이유는 데이터와 더 유연한 결합에 유리하기 때문입니다. 역시 const로 시작하고 컴포넌트 이름을 사용합니다. 여기서 주의할 점은 앞서 설명한 변수명에 사용된 camelCase가 아닌 PascalCase를 사용해야 합니다.


프로그래밍도 엄연한 언어입니다. 언어에는 사회성이 있죠. PascalCase를 쓰는 이유는 react가 첫 문자가 대문자인걸 보고 컴포넌트인 것을 쉽게 구분하게 하기 위함입니다. 이 컨벤션을 벗어나면 compile errorr가 발생합니다. 그리고 함수명 뒤에 '=' 즉 이 함수는 = 뒤의 내용과 같다는 것을 의미합니다.


여기서부터 조금 헷갈립니다. () => { return } 은 기본적인 함수의 정의 포맷에 해당합니다. () =>는 괄호 안에 있는 parameter를 전달한다는 뜻이고 {'안에서 무슨 짓을 하건 마지막에' return '다음에 오는 것을 반환한다'}는 뜻입니다.


이러한 방식을 arrow function이라고 하는데 이 링크에서 좀 더 자세한 설명과 예시를 볼 수 있습니다.


그런데 ({ menus }) =>로 시작하는 이유는 모든 props는 객체 안에 담겨 전달돼야 하기 때문이죠. props가 여러 개 일 때는 쉼표로 그대로 적어주면 됩니다. 그리고 위 코드에서는 return 전에 아무런 행동은 안 했지만 무언가 데이터를 가공할 때는 return 전에 스크립트가 들어갈 수 있습니다. 여하튼 결국 위 코드는 reutrn 다음에 () 괄호에 담긴 내용을 반환합니다.


즉 App.js에서는 starbucksMenus라는 데이터를 menus라는 props로 받은 MenuListSection이 위 내용들을 그대로 App.js에서 반환하는 것입니다. 그리고 그 안에는 다시 menus array를 map함수와 함께 바인딩시킨 MenuCard 컴포넌트가 있습니다.



MenuCard 컴포넌트는 이름처럼 각 메뉴를 보여주는 컴포넌트인데 본격적으로 데이터의 각 항목에 있는 키값들을 유저들에게 보여줍니다. {menu.title}은 위에서 데이터 흐름을 살펴볼 때 미리 준비된 starbucksMenus의 각 항목에 메뉴 타이틀을 뜻합니다. 역시 태그 사이에서 데이터를 불러왔기 때문에 {} 괄호를 사용합니다. 그리고 제일 밑에 각 메뉴의 테이스팅 노트를 나타내기 위해 다시 tastingNotes array를 Chip 컴포넌트에 바인딩시키는 것을 보실 수 있습니다.


그리고 제일 하단에 export default MenuCard는 MenuCard를 디폴트로 내보낸다는 뜻입니다. 이 구문을 추가해야 외부에서 이 컴포넌트를 부를 수 있습니다. 그런데 왜 컴포넌트를 처음 선언할 때 export const로 시작 안 하고 맨 밑에 저 구문을 추가했는지 궁금할 수 있습니다. 이 설명은 지금은 넘어가겠습니다.



3-3 props 들여다 보기

이제 props의 역할과 사용법에 대해 어느 정도 아셨을 것이라 생각합니다. 다만 이름을 정할 때 유의해야 할 점이 있습니다. App.js에서 각 섹션의 props에 데이터를 넘겨주는 코드를 다시 봐보면

props의 이름과 전달하는 데이터의 이름이 같지가 않습니다. 메뉴의 모든 정보를 갖고 있는 데이터는 starbucksMenus라는 이름을 갖고 있고 이를 menus라는 이름의 props로 받고 있습니다. 이처럼 데이터명과 props의 이름이 꼭 일치할 필요는 없습니다. 일치하지 않는 경우가 더 많습니다. 그 이유는 데이터 자체는 특정한 맥락을 그대로 반영하는 경우가 많고 props는 컴포넌트 입장에서 어떤 성격과 기능을 담당할 것인지만 반영이 돼야 관리하기 편하기 때문입니다.


그리고 데이터가 아닌 특정 동작이나 데이터를 연산하는 함수 또한 컴포넌트의 props가 될 수 있습니다. 아래에 TastingNoteSection 컴포넌트를 보면 onTastingNoteClickselectedTastingNote라는 props를 추가로 받고 있는데 이는 테이스팅 노트가 클릭되었을 때 모달을 보여주기 위한 함수와 그 이후에 선택된 테이스팅 노트가 무엇인지를 알려주는 변수에 해당합니다.


이것이 React.js와 Angular와의 차이점입니다. 앵귤러는 저 두 동작을 부모 컴포넌트가 props로 전달하지 않고 자체적으로 해결한 후에 그 결괏값을 부모에게 알려줍니다. 이는 어찌 보면 본능적인 수순으로 보일 수 있지만 이런 쌍방향 데이터 흐름이 반복되면 일관적인 데이터 관리를 해친다는 점에서 React.js가 지양하고 있습니다.


4. 코드 리뷰 가이드: 혼자 공부하는 법

일단 여기까지가 제가 직접 설명한 코드 리뷰 내용이었습니다. 아직 코드 리뷰가 끝난 것은 아니며 다음 주 4화에도 이어서 진행할 예정입니다. 이번 3화에서는


전반적인 프로젝트 구성

props를 통한 데이터 흐름

React.js의 특성과 jsx 작성법

기본적인 javascript 문법



등을 중점적으로 다루었다면 다음 4화에서는

state를 통한 세부적인 인터랙션 구현

MUI 컴포넌트 커스텀 및 스타일링

기타 웹사이트 개선하기

를 다룰 예정입니다.


이제는 위 설명들을 토대로 혼자서 코드를 리뷰하고 공부하는 방법을 얘기하려 합니다. 우리가 프로그래밍도 엄연히 '언어'라고 표현합니다. 그 이유는 일반적인 언어의 특징들을 고스란히 갖고 있기 때문이죠.


문법과 어휘가 있고, 상황에 따른 적합한 관용구가 과거로부터 내려오고 있으며, 언어적 사회성 등의 특징을 갖고 있습니다. 우리가 처음 영어를 배울 때를 생각해 보면 새로운 언어에 익숙해지고 좋은 표현이 무엇인지 많이 보고 배우려고 합니다. 그리고 모든 단어를 외우지 못하지 사전을 찾는 법을 공부하죠.


그리고 앞으로 중요한 능력은 이 사전 활용 능력입니다. 에피소드가 진행할수록 제가 문법에 대한 자세한 설명을 해드리겠지만 그보다 중요한 건 '내가 무엇을 모르는지' 빨리 파악하는 능력입니다. 내가 필요한 것 중 모르는걸 그 어떤 때보다 빨리 찾을 수 있는 시대거든요. 이때 사용하면 좋은 밥법과 링크를 알려드리자면


W3 School

w3에서는 자바스크립트 문법과 html 태그들을 사전처럼 빠르게 찾아볼 수 있는 웹사이트입니다. 따라서 코드 리뷰를 하다 모르는 문법이나 html 태그, 속성, 그리고 css가 나오면 아래 링크에서 한번 정도 살펴보는 걸 권장해 드립니다.


특히 이번주에 다뤘던 arrow function, array 함수는 꼭 한번 살펴보세요.

https://www.w3schools.com/


Chat gpt + Claud 코드 리뷰


그래도 잘 모르겠거나 시간이 별로 없다 하면 모르는 코드를 통째로 복사해서 위 서비스에 알려달라고 하세요. 최근 업데이트된 Chat gpt의 성능을 굳이 고려하지 않더라고 학습용으로는 두 플랫폼 둘 다 훌륭한 길라잡이가 될 수 있습니다. Cluad는 특히 artifact라는 기능을 통해 예시 코드를 직접 렌더링 해서 보여주는 기능도 있습니다.


리액트 공식문서

이미 공유한 적이 있지만 한 번 더 강조드립니다. 특히 jsx 표현 방식, props, 조건부 렌더링 방식을 한번 살펴보세요.

https://ko.react.dev/learn/describing-the-ui



5. 이번주 과제: 내가 모르는 것 + 알게 된 것 조사하기

코드 리뷰를 적으면서 제가 의도적으로 설명을 생략한 부분도 있고, 반대로 의도하지 않았지만 설명이 잘 안 된 부분도 있을 것입니다. 혼자 공부하는 법에서 강조했듯이 프로그래밍을 배우면서 내가 모르는 게 무엇인지(알아야 하지만) 찾아내고 이를 어떻게 해결하는지를 테스트하는 것이 이번주 과제입니다.


위 v0 링크를 보고 프로로젝트 구성과 데이터  > App.js > 섹션 컴포넌트 > 작은 컴포넌트 순으로 리뷰해 보시면서 왠지 중요할 것 같은데 1. 내가 모르겠는 것을 리스팅 해보고 그리고 이를 위의 링크를 통해서 2. 알아보는 것이 이번주 과제입니다.


계속 강조하지만 질문을 던지는 스킬은 개발을 배우는 데 있어 매우 중요합니다. 시간이 부족하다면 2번은 조금 부족할 수 있어도 1번은 꼭 한번 해보시고 이번주 금요일까지 공유해 주시면 되겠습니다.



6. 마치며

이번주는 참가자분이 제시해 준 주제를 하나 골라 v0이 만든 초안을 좀 더 완성해 보고 이를 예제로 코드 리뷰를 해보았습니다. 다음 주에는 한 주 동안 질문을 모아 더 자세한 코드 리뷰를 담은 내용을 발행할 예정입니다. 그리고 최종 완성된 스타벅스 웹사이트를 레퍼런스로 각자 원하는 주제의 웹사이트를 완성시키는 것이 이번 챌린지 최종 목적입니다.




Data Driven Design 공식 홈페이지: http://dddesign.io

dddd의 스레드: https://www.threads.net/@dddesign.io

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari