대환장 빌드 타임
첫날엔 본격적인 체리 앱 개발 이전에, 깃에서 프로젝트를 클론하여 실행시켜 보는게 우선이였습니다.(그냥 클론해서 npm start 하면 되는거 아니야? 했던 제가 미워지는..)
근데 진짜 진짜,, ios와 안드로이드 모두 빌드 성공을 해야했고 저마다 다른 오류가 끊임없이 괴롭혔어요. 너무 괴로웠답니다.. 이때 나는 오류들은 리액트 네이티브 개발해보신 분이라면 한번쯤은 모두 겪으셨을법한 오류들인데, 시간이 된다면 나중에 한번 싹 정리해보도록 할게요!
어찌저찌 많은 도움을 받아 빌드 성공,,!
ios에서는 RN 프로젝트에서 ios 폴더 안에 "xcworkspace 파일"이 있을건데, 그걸 xcode로 열어서 빌드를 하면 되지만, 안드로이드는 조금 다르답니다.
안드로이드에선 RN 프로젝트 안에서 "android" 폴더 자체를 안드로이드 스튜디오로 열어서 터미널에서 설정 해 줘야할 게 있어요. (환경변수 등 기본적인 RN 빌드를 위한 셋팅은 마쳤다고 가정합니다.
그냥 안드로이드 스튜디오에서 빌드를 하게되면 아래와 같은 화면이 뜰거에요
이 문제를 해결하기 위해선 아래 3개의 코드를 입력해줘야 합니다.
npm run start
(VS Code 터미널에서 메트로 서버는 필수로 켜져있어야 합니다.)
source ~./bash_profile
(터미널 상에서 환경변수 등 adb 관련 변경사항을 적용하기 위함입니다. bash_profile이 아니라 zsh로 수정했다면 source ~./zshrc 가 맞겠죠? 이 과정을 안거치면 adb devices 같은 커맨드가 안먹어요🥲)
adb reverse tcp:8081 tcp:8081
(애뮬레이터 기기의 포트를 8081로 변경하는 커맨드)
Styled Component
제가 주로 리액트 네이티브에서 css를 적용하는 방법은 크게 인라인 스타일링(Inline Styling) 방식과 스타일드 컴포넌트(Styled Component) 방식 두가지를 적절히 섞어 쓰는데, 차이를 보면 다음과 같습니다.
인라인 스타일링
return <View
style={{
backgroundColor: 'white',
flex: 1,
justifyContent: 'flex-start',
alignItems: 'flex-start',
}}
/>스타일드 컴포넌트
https://styled-components.com/
아래 커맨드로 라이브러리 설치가 우선입니다.
npm install --save styled-components
import styled from 'styled-components'
const Background = Styled.View`
background-color: 'white';
flex: 1;
justify-content: 'flex-start';
align-items: 'flex-staet';
`;
return <Background />차이가 보이시나요? 인라인 스타일링으로 하면 CamelCase를 이용하여 css 코드를 작성하는점, 스타일드 컴포넌트는 Snake_Case를 이용하여 웹파싱을 할 때처럼 css 문법으로 코드를 작성하는 점부터 차이가 난답니다.
체리 프로젝트를 처음 살펴봤을 때, 대부분이 스타일드 컴포넌트로 css 처리가 되어 있었습니다.
const Styled = {
Title: styled.Text`
width: 'auto';
height: 'auto;
font-size: 14px;
color: 'black'
`,
Button: styled.TouchableOpacity`
width:auto;
height:20px;
margin-left:18px;
`,
};
return (
<GlobalStyled.ViewCol>
<Styled.Title>{title}</Title>
<Styled.Button />
</GlobalStyled.ViewCol>
)이런식으로 js 파일 내에서 여러개의 스타일드 컴포넌트를 Styled라는 JSON 형식으로 묶어 렌더링 하는 형식이었습니다.
다른 개발자 분이 말씀하시길, 개발팀에서 UI 작업이 끝나고 디자인팀과 협업해서 디자인 수정을 할 때 스타일드 컴포넌트로 처리되어있다보니 이 요소가 어떤 컴포넌트인지 확인하기도 어렵고, 렌더링 부분과 JSON 부분을 같이 봐야하니 더 시간도 오래걸리는 단점 이 있는 것 같아 인라인 스타일링으로 변경하길 원한다고 하셨습니다.
자주 쓰이는 공통적인 스타일들을 제외하고는 인라인 스타일링으로 수정하는 거대한 css 공사가 시작되었습니다. 다른분들은 RN에서 어떤식으로 css를 처리하고 있는지 궁금하네요🤔 개인적으로는 아직 Styled Component가 더 가독성 있어 보여서 잘 쓰고 있기는 합니다만.. 네이밍도 중요한것 같아요.
Branch? Pull Request?
다른 프론트 인턴 분과 파트를 나누어서 스타일링을 마친 뒤
자바님 PR좀 날려주세요~
네...?
ㅋㅋㅋㅋㅋㅋㅋ부끄럽지만 아직 PR이 뭔지 몰랐던,, 저였습니다.
지금까지 한 소규모 프로젝트에서는 main에 바로 push 하는 방식으로 작업해온 저였기에, PR이라는 용어가 생소했답니다🙀
그래서 작성하는 PR 하는 법
(포크 부분은 생략 가능합니다.)
먼저 타겟 프로젝트를 포크(fork)합니다. 깃허브 레퍼지토리 우상단에 다음과 같이 있을거에요! 포크하게 되면 내 레파지토리에 포크한 프로젝트가 뜨게 됩니다. 
fork로 생성한 본인 계정의 저장소에서 clone or download 버튼을 누르고 표시되는 url을 클론합니다.
git clone https://github.com/sujin-kk/test.git
마지막으로 로컬 저장소에 원격 저장소를 추가합니다. 위 작업과 동일하게 github 저장소에서 clone or download 메뉴를 통해서 확인한 url을 사용하면 됩니다!
git remote add '별명' https://github.com/원본계정/test.git
clone을 하면 origin이라는 별명이 기본적으로 추가되기 때문에 아래와 같이 입력해도 됩니다.
git remote add origin https://github.com/원본계정/test.git
원격 저장소 설정 후 확인은 다음과 같습니다.
git remote -v
이제 본격적인 PR 날리기를 시작합니다.
우선 저는 자신의 브랜치를 파서 작업하는 것을 추천합니다!
https://velog.io/@kim-jaemin420/Git-branch-naming
브랜치도 네이밍하는 규칙이 있답니다. 잘 정리된 벨로그 글을 첨부합니다.
브랜치를 하나 생성합니다.
git branch '브랜치이름'
생성한 브랜치로 이동합니다.
git checkout '브랜치이름'
코드 작성 뒤 add, commit, push를 진행합니다.
git add . (or git add '파일이름')
커밋메세지에도 규칙이 있답니다. 무분별한 메세지가 쌓일 수록 가독성은 떨어집니다.
https://velog.io/@kkimbj18/Git-%EC%BB%A8%EB%B2%A4%EC%85%98
git commit -m "커밋메세지"
푸쉬할 땐 브랜치 이름을 명시해주어야 합니다.
git push origin '브랜치이름'
그럼 아래와 같이 github 레파지토리에 풀리스퀘스트 버튼이 활성화 되어 있습니다.
버튼을 누르고 PR 메세지를 작성한 뒤 PR을 생성합니다!👏🏻👏🏻
마이스는 Issue / 작업내용 / 코드변경사항 / 스크린샷 첨부 / 참고사항 등으로 섹션을 나누어 작성 할 수 있도록 PR 양식이 정해져있었답니다.
이제 원본 저장소 관리자가 PR을 보고 merge 여부를 결정합니다. 이 때 코드리뷰를 진행하기도 해요!
merge가 완료되면 원본 저장소의 코드와 동기화 시키기 위해 pull을 해주어야 합니다.
git pull origin main
PR을 마친 브랜치는 삭제합니다.
git branch -d '브랜치이름'
이렇게 험난했던 빌드과정을 거치고, css 작업을 한 다음 수정사항을 PR 보내고 첫날을 마쳤답니다!👏🏻짝짝인턴 과정중에 언제가 제일 힘들었냐 하면 전 주저하지 않고 처음 실행 시킬 때라고 할겁니다...
프론트엔드 인턴분들이 실행시킬 때 거의 반쯤 녹초가 되자 대표님은 웃으시면서
'원래 첫 시작이 제일 힘든거에요..허허😀'
라고 하셨다죠.. ㅎㅎㅎ 이제 본격적으로 어떤 업무를 맡게 되었는지 작성해볼게요!
