경북대 FE_정서현_1주차 과제 Step1/2/3 #46
Conversation
- Removed package-lock.json - Added yarn.lock
- Created src/assets for static assets - Created src/components for React components - Created src/constants for constant values - Created src/hooks for custom hooks - Created other necessary directories
- .eslintrc.cjs, .prettierrc, .vscode/settings.json, package.json, tsconfig.json 설정 파일 수정 - 코드 스타일 수정 (src/App.tsx, src/index.tsx, src/styles/GlobalStyle.tsx) - public/index.html, yarn.lock 파일 수정
There was a problem hiding this comment.
안녕하세요!
제가 생각하는 답을 알려드리는 것보다 직접 고민해보시는게 훨씬 성장에 도움이 될 것 같다고 생각해요.
코멘트를 보시고 한 번 고민해 보시면 좋겠습니다 ㅎㅎ
컴포넌트에 남겨진 코멘트들은 모든 컴포넌트에 적용되는 코멘트라고 생각해주시면 감사하겠습니다~
커밋 메시지 작성에 익숙해지기 위해 작은 작업 단위마다 쪼개서 커밋을 해보았습니다.
그러다보니 생긴 의문점인데, 어떤 작업 단위로 커밋을 하면 좋을지 더불어 현업에서는 어떻게 커밋 컨벤션을 지키며 메시지를 작성하는지가 궁금합니다!
https://www.conventionalcommits.org/en/v1.0.0/#examples
요것이 국룰이라고 할 수 있겠습니다.
작업 단위로 커밋하고, 메시지는 위의 컨벤셔널 커밋이 제안하는 형태가 일반적이에요.
다만, 지금처럼 PR을 사용해 한 PR에 여러 커밋이 포함된 형태의 협업 방식 말고도 다른 방식이 있는데요,
예를 들어 Gerrit이라는 툴을 활용한 TBD 전략의 git 관리에서는 PR이라는 개념이 없습니다.
모든 커밋이 하나의 완성된 작업을 보장해야하고, 각 커밋은 리뷰 후 즉서 main에 병합되면서 배포됩니다.
그러니까... dev 브랜치나 까나리 브랜치를 별도로 두지 않는다는 이야기인데, 나중에 한 코드베이스에서 여러 조직이 동시에 수정할 경우 충돌 해결에 대한 고민을 하게 되실때 이 TBD를 찾아보시게 될 거에요 ㅎㅎ
Storybook component 를 만들때 story 파일을 잘 구성하는 팁 같은게 있을까요? 생소한 구성이라 어려웠습니다.
스토리북을 왜 사용하는지부터 제대로 정의해야 작성 방식도 명확해지겠죠?
왜 스토리북을 사용하셨나요? 이 프로젝트에서 스토리북은 무슨 역할인가요?
.eslintrc.cjs
Outdated
There was a problem hiding this comment.
저는 특정 룰을 선호한다기 보다는 팀원들과 논의해서 정하는 편입니다.
선호하는 규칙은 따로 없는데요, 다만 airbnb 규칙은 불호에 가깝습니다 ㅋㅋㅋ
이유는 너무 빡빡하게 굴어서.. 인데요. 가끔 '이게 왜?'라는 느낌을 받을 때가 많습니다.
그럴 때마다 일일히 규칙을 꺼주는 것도 번거롭구요.
개인적으로는 린트 룰을 어떻게 설정하는지는 그리 중요하지는 않은 것 같습니다.
물론 정말 중요한 룰이 몇개 있긴 하지만요.(react hooks 관련 룰 같은 것들이요!)
룰의 구체적인 내용보다는 '모든 팀원이 같은 스타일의 코드를 짜도록 강제한다'는 개념이 중요하다고 생각해요.
그래서 지금 당장 어떤 룰은 좋아~ 어떤 룰은 싫어! 라고 생각하기보다는 개발하시면서 이것도 써보고, 저것도 써보시는 것을 추천드려요.
다만, eslint와 prettier를 함께 쓰실때는 각각의 도구가 어떤 역할을 담당하는지 잘 구분하시면 좋을 것 같습니다.
prettier는 텍스트를 가지런히 정돈하는 역할로 사용하고, eslint는 코드를 작성하는 방식에 대한 규칙으로 사용하시게 될텐데요.
예를 들어, prettier는 들여쓰기나 따옴표 등을 담당합니다.
현재 eslint 규칙에는 따옴표 규칙이 포함되어 있네요! 이런 룰은 prettier가 담당하는 것이니 제거하는게 좋겠죠?
| src | ||
| ├── api // API 호출 및 외부 서비스와의 통신 로직 | ||
| ├── assets // 이미지, 아이콘 등 정적 파일 | ||
| ├── components // 재사용 가능한 React 컴포넌트 |
There was a problem hiding this comment.
음.. 제 생각으로는 재사용 불가능한 컴포넌트들은 특정 페이지에서만 사용되므로
해당 페이지 컴포넌트 내부에 작성해야 한다고 생각합니다.
따라서 page 폴더에 작성됩니다.
|
|
||
| return ( | ||
| <button | ||
| className={`btn ${buttonStyles} btn-${theme} btn-${size}`} |
There was a problem hiding this comment.
emotion/css를 사용하신다면 css prop을 사용하는 것도 추천드려요~!
https://emotion.sh/docs/css-prop
| } | ||
|
|
||
| const Button = ({ theme, size, disabled, onClick }: ButtonProps) => { | ||
| const buttonStyles = css` |
There was a problem hiding this comment.
현재 방식은 스타일을 만들어주는 곳과 className을 동시에 신경써야해서 좋은 방식으로 보이지는 않습니다.
굳이 추가적인 className을 사용하지 않고, buttonStyles 하나만 사용해서 스타일을 적용하는 방식도 있으니 한 번 고민해 보시면 좋겠어요!
| const buttonStyles = css` | |
| const buttonStyles = ( theme, size ... ) => css` |
There was a problem hiding this comment.
제안해주신 코드를 봤는데
'추가적인 className 을 사용하지 않고' 라는 말이 이해가 잘 되지 않습니다 ㅠㅠ
제대로 이해한지는 모르겠으나 코드를 고쳐봤는데 제가 이해한 부분이 맞을까요?
const Button = ({ theme, size, disabled, onClick }: ButtonProps) => {
const buttonStyles = css`
/* css 부분 생략 */
`;
return (
<button
css={buttonStyles}
type='button'
disabled={disabled}
onClick={onClick}
>
Kakao
</button>
);
};
| theme: string; | ||
| size: 'small' | 'medium' | 'large' | 'responsive'; | ||
| disabled: boolean; | ||
| onClick: () => void; |
There was a problem hiding this comment.
onClick 함수는 아무 인자도 없는게 맞을까요~?
우리는 클릭 이벤트가 발생할 경우 많은 것을 알 수 있을텐데요!
| interface ContainerProps { | ||
| maxWidth?: string; | ||
| children?: string; | ||
| flexDirection?: 'row' | 'column'; | ||
| justifyContent: | ||
| | 'center' | ||
| | 'flex-start' | ||
| | 'flex-end' | ||
| | 'space-between' | ||
| | 'space-around'; | ||
| alignItems: 'center' | 'flex-start' | 'flex-end' | 'baseline' | 'stretch'; | ||
| } |
| flexDirection, | ||
| justifyContent, | ||
| alignItems, | ||
| ...props |
| children: React.ReactNode; | ||
| } | ||
|
|
||
| const Grid = ({ gap, columns, children, ...props }: GridProps) => { |
| <div | ||
| className={css` | ||
| display: grid; | ||
| gap: ${gap}px; |
There was a problem hiding this comment.
gap을 반드시 px로만 지정할 수 있나요?
만약 %나 rem 등 다른 단위를 사용하고 싶다면 어떡하면 좋을까요?
| height: auto; | ||
| object-fit: cover; | ||
| aspect-ratio: 1/1; | ||
| border-radius: 7px; |
There was a problem hiding this comment.
홀수 px을 사용하시는 경우가 많군요!
일반적으로는 8px단위나 4px단위를 사용하는 경우가 많습니다. 왜 짝수 px 단위를 사용하는지 한 번 찾아보시면 좋을 것 같아요 ㅎㅎ
FE 카카오 선물하기 1주차 과제: React 기초
✓ 1주차 질문
🤔 1. Webpack 은 무엇이고, 어떤 역할을 하고 있나요?
Webpack은 모듈 번들러 입니다. 웹 어플리케이션을 개발할 때 다양한 종류의 파일(JS, TS, CSS, 이미지) 등을 사용하게 되는데, Webpack 은 이러한 파일들을 의존성 관계에 따라 하나의 번들 파일로 결합 시켜줍니다!🤔 2. 브라우저는 어떻게 JSX 파일을 읽을 수 있나요?
Transpiler의 역할을 수행합니다.➞ Babel이 JSX 코드를 표준 JavaScript 코드로 변환되고
➞ 변환된 JavaScript 코드가 브라우저에서 실행됩니다.
🤔 3. React 에서 상태변화가 생겼을 때 어떻게 변화를 알아챌 수 있나요?
멘토님께 드리고 싶은 질문들
ESLint 와 Prettier 같은 경우 여러 자료들을 찾아보며 하나로 만들어 보았습니다.
그래서 혹시 불 필요한 세팅이 있지는 않은지 확인 부탁드립니다.
또, 선호하시는 세팅이 있으시면 알려주시면 감사하겠습니다!
커밋 메시지 작성에 익숙해지기 위해 작은 작업 단위마다 쪼개서 커밋을 해보았습니다.
그러다보니 생긴 의문점인데, 어떤 작업 단위로 커밋을 하면 좋을지 더불어 현업에서는 어떻게 커밋 컨벤션을 지키며 메시지를 작성하는지가 궁금합니다!
Storybook component 를 만들때 story 파일을 잘 구성하는 팁 같은게 있을까요? 생소한 구성이라 어려웠습니다.
1주차 체크 리스트
CRA로 만들어진 프로젝트에 Typescript 로 세팅
ESLint 및 Prettier 추가 후 자신만의 세팅하기
폴더 구조를 나누고 README.md 에 폴더 구조에 대한 설명 작성
emotion 스타일 라이브러리 추가, reset CSS 적용
.gitignore 를 추가, 프로젝트에 불 필요한 코드들은 정리
코딩 컨벤션 준수
기능 단위로 적절하게 커밋
Storybook 을 사용하여 재사용 가능한 컴포넌트 구현
ReadMe 에 주어진 퀴즈에 답변
📌 프로젝트 내 폴더 구조