React Native
React Native의 힘든점
디버깅이 힘들다!!
그래서 크롬 디버거를 쓰는걸 추천한다. command + m
또 네트워크 부분이 안보임 + 네트워크 부분을 보기 위해서는 react native flipper를 써야함
이렇게 네트워크 부분도 확인 할 수 있게 된다.
주소가 없는 차이에 대한 디테일
웹과 앱 사이에는 다양한 것들이 있음
네가지, ionic4, React, Next, React-Native가 있다고 해보자
ionic4 - 웹과 앱을 한번에 만들어주는 친구다 (배포까지 가능함)
근데 ionic 태그를 써야해서 React나 React native로 이동하지 못함, 이것만 써야하는 단점이 있음
일단 코드들이 다 다름
head같은경우는 React는 helmet이라고 있음(우리는 next의 Head썼었음)
Router의 부분은 ReactRouter, Next는 router만 써도 자동으로 라우팅됨, React-native는 ReactNavigation이 다름
만약에 지금 하던것에서 순수 React로 넘어가려면 Router부분만 새로 익히면 됨
React-Native 로 넘어가려면 당연히 ReactNavigation 부분이 필요
그래서 사용해야하는 기술들은 그렇게 좋지 않음,
최신기술도 마찬가지, 나왔지만 이후에 사용이 많이 되야하는 애들을 써야지, 갑자기 단점이 발견되서 죽을수도 있기 때문, 그니까 올인하지 말기
**PC앱 만들기 - Electron
React를 사용해서 PC앱도 만들 수 있음, 대표적으로 슬랙이 이걸 사용한것
그래서 어디서 비교해서 아냐????
npm-trend
https://www.npmtrends.com/
(vue보단 react를 많이 쓴다는걸 볼 수 있음)
google trend
https://trends.google.com/trends/?geo=KR
그래서 내가 배우는게 트렌드에 반영이 되는 건지, 해도되는건지 잘 알아보고 할것..!
React Navigation
독스의 중요성
독스로 들어가보자 - 독스는 이제 보면 패턴이 보인다 getting started로 시작세팅하고 guides에 예제들이 좀 있는셈
취직했다고 해보자 , 취직했다고 해서 맘놓고 모든걸 편하게 물어볼 순 없음, 그분들도 할일이 있으니까. 그래서 그때야말로 독스, 공식문서가 중요해짐
보고 외우라는건아니지만 보면서 익숙해지는 것이 중요함 - > 한번 익숙해지만 엄청 큰 변화가 생기지 않음(사라지지도않음) -> 결국에는 내 지식이 되는것 -> 마지막에는 한번씩은 다 익힌셈이된다
꾸준하게 좀 보셈, 옆의 개발자도 이거 보고 있을 것
돌아가서,
React Navigation을 이용해서 화면을 이동시킬꺼면 Tab navigation, Hello React Navigation ,Moving between screens 로 하면 편할것임!
모바일에서 뒤로가기 버튼으로 이동한것도 기억할것임, 이건 그 전 페이지와 현재 페이지가 stack으로 엮어있음, stack navigation인것임
메뉴도 stack으로 묶여있음, 근데 만약에 홈에서 아예 메뉴1로 넘어간다고 하면 그 연결된 stack들에서 벗어남 그걸 탭이라고하는것
react native async storage
기존 react-native 에 있던 async storage에 분제점이 발견되서 새롭게 나옴
취업준비..? 팁
보통 과제를 받아서 만들텐데 필수와 보너스 부분이 있다.
필수
-
CSS는 기본이다 (반응형까지 들어오면좋죠)
-
기능구현도 기본임 + 근데 거기서 보기도 좋아야함
-
컴포넌트 재사용성 높이기
-
글로벌 스테이트 활용하기
-
gif로 요약해서 돌아가는 모습 보여주기
=> 이정도면 충분할 수 있음
보너스
-
useCallback 으로 최적화
-
도메인 구입 및 SSR로 배포함
-
타입스크립트+
-
리팩토링
-
크로스브라우징 문제 해결
지원은 1년차로만 지원하지 말고 능력을 충분히 길러서 경력직에도 도전해볼것!! 가능한가
서비스 배포 이후
서비스를 배포한다고 땡이 아님 잘 돌아가나 테스트를 해봐야함
등록하기를 눌러본다던가, 멤버가 제대로 나오나 본다던가..
사이트 배포 이후에 운영한다고 하면(사람들이 접속할 수 있게)
구글에 검색이 되게끔 웹마스터 (구글 웹마스터, 네이버 웹마스터 등등) 에 등록하기를 해야한다. 그래야 검색에 노출됨
이제 서비스가 커져서 새로운 기능을 추가해야함, 버전 2를 업그레이드 하기 위해선
production 에 배포가 되어있고 버전 2 는 dev와 local에서하고 있음,
그 사이에 이제 평가하기위해 staging 단계가 있는것 여기서 버전2를 올려놓고 확인 후에 production으로 올림(이전에 해봄)
근데 올릴때 새로추가한건 되는데 다른곳에서 에러가 났음(테스트는 새로만든기능만 했으므로)
그럼... 어디가 어떻게 문제인지 하나하나 찾아봐야하는것
--> 여기서 테스트 코드가 필요하게됨
jest라는게 있음
컴포넌트를 만들고 그동작을 체크하는 테스트 코드를 만들어서 하는것임
- 여기서 반응형까지 하면.. 세배?!!?!?
이걸 만드는 방식도 몇가지가 있음
기능만들기-> 테스트하기
테스트코드 먼저 만들고 - > 그걸 기반으로 만들기(TDD, Test Driven Development)
더 안정적으로 개발할 수 있지만 투머치가 될 수 있음/만약 이미 가지고있는 서비스가 크다면 새로운걸 붙일때는 이런 방식으로 하는게 좋을 수 있음
깃을 이용한 협업, git workflow
이게 젤 유명한 것
여태까지 우리는 master라는 브랜치를 써왔음
하지만 master는 배포할 때 쓰는거였고 develop이라는 branch를 쓰게됨
근데 누구나 develop branch에 올리지 않고 feature이라는 branch를 만듬
거기서 세분화된 기능을 만들어서 올린다.
feature -product , fewture -board 를 만들어서 팀장에게 올리고
팀장은 develop에 올리는 셈
그럼 release, hotfix branch는 뭐냐?
develop개발을 끝냈다고 해서 바로 배포할 수는 없음, 여기서 release로 옮겨서 버그만 잡는거다 -> 더이상 버그가 없으면 드디어 마스터로 최종배포할 수 있게됨
hotfix같은경우는 realease에서 문제가 없어서 마스터로 옮겼는데 문제가 생겼을 때 hotfix에서 고치고 master로 다시 보내는 역할임
실제 깃을 사용한 개발순서를 보자
1명의 git repository (프로젝트)를 만든다
그리고 개발하는 사람들이 그걸 가져와서 그걸 바탕으로 만든다 (fork)
그럼 원본은 아니고 복사본을 각각 가지고있는 셈
그럼 그걸 git clone을 통해서 자기 깃으로 가져옴(원본이 아님)
여기서 근데 master에서 하지 않고 feature브랜치를 만들어서 함
그이후 push 를 하게 되면 자신의 git으로 가져오게됨
개발 후 pull request를 하면 (feature-1, 2, 3)원본인 git repository로 가게됨
그럼 원본 git에서 받을지 말지를 골라서 수정할 수 있음
(branch는 develop에 넣는것)
보통 이런 과정을 아침에 한번 함
이후 변화가 일어난걸 다 공유하기 위해서 원본에서 pull을 해옴
이후 다시 과정을 반복함
근데 이전에 했던대로 명령을하면 원본이랑 내사본이랑 구별이 안됨
그래서 원본을 upstream이라고 해서 git pull upstream, 그리고 push 는 git push origin으로 할 수 있도록 함
요약
1. upstream에서 fork를 따옴
2. 그걸 origin 으로 가져온다음 clone을 통해서 내 코드로 가져옴
3. feature브랜치에서 나는 기능개발을 함
4. 완료되면 origin으로 올린 후 upstream 으로 pull request를 함
5. 아침이 되면 upstream에서 pull request를 받을지 말지 고민
6. 다 결정이 되서 나서 upstream에서 업데이트 된 코드들을 pull로 가져옴
7. 3번으로 돌아가서 다시 개발시작
주의점
feature에서 각각 다른기능을 만들고 있으면 문제가 없지만
만약 서로 겹치는 feature를 만들게되면? 문제가 생김
공통기능은 더 중요하다. 그래서 보통 경험이 많은 사람들인 시니어급이 하게됨
origin 과 upstream 세팅하기
git remote add upstream 원본주소
git remote -v 로 확인할 수 있음
이렇게해야 upstream에서 pull을 할 수 있게됨
기능은 이제 원본 git으로 가서 issues에 하나씩 추가하고 처리해나가는 식으로하는게 좋음
하루 가능한 양 + 1일 1커밋 하는 것이 죠음
->> 왜냐? 누군가 게시판 만들기라고 이슈라고 만듬, 하루가 아니고 3일동안 밤새서 만듬, 문제는 3일동안 만든 이슈를 pull request를 하려고 봤더니 다른사람들이랑 만든것과 충돌이 남
->> 그럼 3일동안 만든거 버리기 vs 충돌한거 다같이 시간내서
->> 둘 다 좋은결과가 아님
그래서 잘게 쪼개서 하는 느낌으로 하면 됨
실제 해보기
브랜치 바꾸기
git checkout -b feature-issue-2
그럼 이렇게 만들고나서 branch에서 add commit push 하면됨
이후 pull request, new pull request ->
feature 부분을 고르고 오리진에서 마스터로 보내는 것
이제 원래 브랜치 계정으로 가면 merge confirm 으로 develop으로 합칠 수 있게됨
그럼 통과가 된다.
그 이후로 이제 받와야함
git checkout master
마스터로 바꾼 이후에 git pull upstream master
그리고나면 이제 공식으로 바뀐 원본을 가져올 수 있게됨
만약 기능 하나를 만들고 하나를 더 만들고 싶다면??
git checkout master 로 마스터로 돌아가서
git checkout - b feature-새로운기능 이렇게하던지
물론 전에 만든 이슈에서 계속 만들 수 있지만 브랜치들을 독립적으로 보고 기능하나를 했으면 Master에서 새로 다시 하는 것이 중요함 !!
-> 서로 연관이 없는 기능을 만드는 것이 좋음
