일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- schema-first
- react.js
- angular
- apollo client
- graphql
- goorm.io
- 함수형
- Front-End
- VanillaJS
- 리액트
- 코딩
- Ramda.js
- 개발
- code-first
- React
- vue.js
- 자바스크립트
- 프로그래밍
- Design Pattern
- 프론트엔드
- It
- VUE
- JavaScript
- Funtional programming
- ECMAScript6
- context api
- Programming
- 디자인패턴
- Node.js
- ELECTRON
공부하는 블로그
Vue 하다가 React 하는 개발자 이야기 2 본문
Vue 하다가 React 하는 개발자 이야기 2
-
어제 올렸던 내용에 대해서는 일단 apollo client의 상태 관리 시스템은 기각하고 redux를 쓰는 것으로 결정을 했습니다.
-
커뮤니티에서 자문을 구한 결과, 아직 아폴로 상태 관리 시스템은 프로덕션에 적용하기에는 무리라는 판단이 들었습니다.
-
전 회사에서도 node.js의 ORM을 선택할 때
-
star 수
-
활발하게 commit이 되고 있는가?
-
문서화가 잘 되어 있는가?
-
현재 프로젝트와 궁합이 잘 맞을까?
등을 고려해서 선택했던 것이 TypeORM 이었는데, 사용하다보니 부족한 점이 많았습니다. 또한 처음 접하는 이슈 등에 대해서는 이슈 트래킹이나 검색도 잘 안되어 고생하는 경우도 있었습니다.
이때
1) 스타 수로만 프로젝트를 판단하면 안 되겠구나.
2) contribution과 이슈 등록 등의 참여가 중요하겠다.
3) 프로덕션에 실제 적용한 사례가 있는가? 충분히 검증이 되었는가도 중요한 지표가 되겠다.
하는 것들도 많이 느끼게 되었습니다.
-
아무튼 이렇게 해서 아폴로 클라이언트의 상태 관리 시스템은 기각이 되고, 다시 논의를 하는데 우선적으로 제 의문은 과연 상태 관리가 필요한 상황인지에 대한 것이었습니다.
-
제가 우려되었던 점은, 괜히 오버 엔지니어링을 하는 건 아닌가? 하는 생각이 제일 컸습니다. 닭 잡는데 소 잡는 칼 쓸 필요는 없다는 생각이 있었기 때문입니다.
-
동료 개발자분께서는 코딩을 하며 몇가지 원칙을 지켜서 작업하고자 하는 의도가 있으셨고, 그에 따라 상태 관리는 필요하다고 이야기 하셨습니다.
-
컴포넌트 간 상태 전달을 할 때나, 단방항 바인딩 등 리액트의 특성이 있고, 또한 컴포넌트를 제작할 때도 단일 책임 원칙을 비롯해 지키고자 하는 원칙들이 있음을 말씀하셨습니다. 그러다보니 상태 관리는 필수적으로 필요한 상황임을 이해하게 되었습니다.
-
결국에는 남은 선택지는 Redux와 context api 인데, 동료 개발자분께서 이야기 하신 부분은
-
Graphql의 경우 overfetching과 underfetching을 해결한 기술이다. Redux는 REST API를 사용할 때 더 필요한 기술이지, GraphQL에서 Redux를 쓰는 것은 결이 맞지 않다는 말씀을 하셨습니다. (사실 이 부분에 대해서는 이해가 잘 안되고, 공감하기도 좀 어려웠네요)
-
context api의 경우 가볍게 쓰기는 좋지만 이 역시 앱 규모가 커지면 관리의 어려움이 있다고 합니다.
- 결론적으로는 가장 널리 쓰이고 있고, 참조할만한 자료가 많은 Redux를 택하는 것으로 방향이 정해졌습니다. 닭 잡는데 소 잡는 칼 쓰는 격은 아닌가? 라는 생각이 있었지만, 어차피 쓰는 칼인데 소 잡는 칼로 닭 잡으면 뭐 어떠냐. 라는 의견이 있었습니다. 😅
- 개인적으로는 context api를 써보고 싶은 마음이 있었는데, 이 역시도 Redux에서 개념을 빌려온 부분도 있어서 우선적으로는 Redux에 대해 익숙해지는 것이 좋겠다는 생각도 들었습니다.
- 또한 이야기를 나누다보니, 동료 개발자분께서 첫 실무 프로젝트에 들어가다보니 내심 부담이 되셨던 것 같습니다. 기술 도입에 앞서서 앞으로 어떻게 될지에 대한 예측이 불가능하니, 그 부분에 대한 어려움이 있으시더군요.
- 완벽한 프로그램, 흠이 없는 프로그램을 만드는 것은 불가능하다 생각합니다. 인간이 만들기 때문이지요. null 참조를 고안했던 토니 호어(Tony Hoare) 역시도 null을 처음 만들때 이것이 "10억 달러짜리 실수"가 될 것이라고는 생각했을까요?
- 예측이 안 되는 일을 미리 걱정하기보다는 우선은 기술을 학습하고, 적용하며 부딪혀 보며 생각하자고 의견이 모였고, 이제 Redux를 적용해가고자 합니다. Redux가 우리 프로젝트에 적합하지 않다 느껴지면 다른 대안을 찾아보아도 되지요.
- 즐겁게 개발해가보고자 합니다 :) 오늘도 하루를 마칩니다.
참고 내용
- https://react.vlpt.us/redux/
- https://dev.to/ayushmanbthakur/redux-vs-context-api-3182
'React' 카테고리의 다른 글
Vue 하다가 React 하는 개발자 이야기 6 (0) | 2020.03.09 |
---|---|
Vue 하다가 React 하는 개발자 이야기 5 (0) | 2020.03.06 |
Vue 하다가 React 하는 개발자 이야기 4 (0) | 2020.03.06 |
Vue 하다가 React 하는 개발자 이야기 3 (2) | 2020.03.05 |
Vue 하다가 React 하는 개발자 이야기 1 (0) | 2020.03.04 |