백엔드만 한참 해온 개발자들이 프론트하면 항상 이렇게 생각하더라구요, 결국 잘 못한다는 뜻입니다. 백엔드한다고 프론트 못한다고 생각하진않는데 대부분 생각이 유연하지는 못하더라구요. 그리고 프론트에서 OOP안쓴다고 생각하는것도 되게 잘못된 방향으로 생각하는거같네요. 대부분 프론트개발자들이 수준미달이 많긴합니다만 OOP에서 중요하게 생각하는 SOLID원칙을 생각하지않고 좋은코드를 짤수가없습니다. 리액트가 함수컴포넌트라는 네이밍을써서 FP랑 되게 착각을 많이하던데 실제로는 컴포넌트 코딩하는 패턴이나 상태관리 도구 사용한는거보면 OOP에 가깝습니다...FP는 순수함수를 디폴트로 가져가는데 함수컴포넌트 개발할때 그런식으로 개발하지도않고 useEffect는 이름부터 사이드이펙트입니다...
아직 공부하는 학생 입장에서 찍어서 향만 맡아본 입장이라 많이 많이 부족한 점이 있을 수 있습니다. 그리고 제가 말하기에 지식이 부족한 React에 대한 내용보다는 함수형 프로그래밍에 초점을 맞추어 작성하였습니다. 혹시 틀린 내용 있으면 지적해 주시면 수정하도록 하겠습니다! 1. OOP와 FP의 관점 차이 개인적으로 OOP와 FP는 세상을 모델링하는 관점에 근본적인 차이가 있다고 생각합니다. "객체지향의 사실과 오해"라는 책을 읽고 느낀 점은 OOP는 세상을 **여러 개의 서로 상호작용하는 독립적인 object들**(1)로 구성한다고 느꼈고, 인터넷 자료(2)들을 참고하면서 FP는 세상을 **불변하고 내부를 읽을 수 있는 data와, data를 순수 함수를 이용해 다른 data로 만들어주면서 만드는 unix pipe 같은 흐름**으로 구성한다고 느꼈습니다. (짧게 표현하다 보니 뉘앙스가 빠진 부분이 있을 것 같은데 지적해주시면 수정하겠습니다!) 그런 의미에서 OOP 전문가의 입장에서 FP를 보면 state를 관리를 안하면 그 state를 여러 곳에서 접근을 할 텐데 이걸 어떻게 관리하냐는 물음은 당연히 나올 수 있다고 생각합니다. 그리고 그에 대한 해답은 기본적으로는 변경가능한 state를 만드는 것이 아니라, 변경 불가능한 data를 이용해서 누가 접근하는지 자체를 신경쓰지 말게 하고, data는 한 가지 방향으로 흐르게 해서 각 지점에서의 상태를 파악할 수 있게 하는 것으로 저는 이해했습니다. (1) 생각을 정리하여 수정중입니다. (2) 이것저것 찾아보긴 하는데 대표적인 것으로 다음이 있습니다. F# 언어를 이용해 설명을 하는데 언어와 상관없이 도움이 되었던 것 같아요. fsharpforfunandprofit.com/ 2. 객체지향과 설계의 구분 개인적인 의견으로는 어떤 패러다임이든 일정 규모 이상의 프로젝트에서는 짜임새 있는 설계는 필요하다는 생각입니다. 그리고 SOLID design principle은 객체지향에만 쓸 수 있는 개념이 아닌, 함수형 패러다임에서도 언어가 지원해준다면 따르면 손해 안 보는 좋은 설계 원칙이라고 생각됩니다. 그리고 많은 함수형 언어에서 이미 SOLID에 대응되는 디자인 원칙이 정립되어 있는 것으로 알고 있습니다. 예를 들면 Interface 대신 함수 타입에 적절한 명세의 이름을 붙여준다면 같은 명세를 갖는 다양한 함수들로 구현을 교체할 수 있고, 함수를 parameter로 갖는 고차 함수를 통해 생성자 주입에 해당되는 Dependency injection을 수행할 수 있습니다. 따라서 프로그래밍 패러다임과 좋은 소프트웨어 설계는 X축과 Y축처럼 서로 독립적인 개념이 아닐까 싶은 생각이 듭니다. 객체지향적인 패러다임을 준수하면서 짜임새 있게 짤 수도 있고 막 짤 수도 있듯이, 함수형 패러다임을 가지고도 짜임새 있게 짤 수 있고 막 짤 수도 있다고 생각합니다. 따라서 저는 함수형 코드가 짜임새가 없다기보다는 객체지향이든 함수형이든 제대로 된 설계가 없는 코드가 짜임새 없는 것이 아닐까라고 생각하였습니다. 그리고 주제에 벗어나는 얘기지만 오해를 막기 위해 첨언하자면, 짜임새 없는 코드도 환경이 빨리 바뀌는 상황에서는 최선의 선택이 될 수도 있다고 생각합니다. 3. class-enum에 대한 기능을 Typescript에서는 tagged union으로 나타낼 수 있으며 compiler가 각 케이스별로 타입 추론도 해 주는 것으로 알고 있습니다. 혹시 이 부분에 부족함을 느끼셔서 라이브러리를 만드신 것인지요? 4. 좋은 Food for thought를 제공해주셔서 감사드리며, 당돌한 글 읽어주셔서 감사드립니다.
취준생 때 프론트를 굉장히 얕게 공부하고 취업한 이후로는 회사에서 백엔드 개발만 하고 취미로만 프론트를 조금 다루고 있어서 프론트 쪽은 마땅히 물어볼 데도 없고 공부할 우선순위도 낮아 방치하고 있었는데요, 공식문서나 블로그에서 제대로 다뤄주지 않는 의문을 영상에서 제시해주시고 재야에 숨어있는 프론트 개발자분들이 달아주신 답변과 개인의견을 읽어보니 갖고 있던 의문이 많이 해소되고 생각이 좀 정리가 되네요. 생각지도 못한 좋은 주제 감사합니다.
저는 React의 JSX와 상태 관리에 불편함을 느끼고서 Angular로 넘어왔는데 현재도 정말 만족하며 쓰고 있습니다. 특히 Ivy 랜더링 엔진으로 변경된 이후 정말 빠르고 가벼워졌습니다. 아직도 과거 AngularJS 시절의 이미지를 그대로 갖고 계신 FE 개발자 분들도 계시는데 다시 한번 해보시길 권해드립니다. 다만 사내 React 개발자분들 얘기를 들어보면 그냥 대세니까 핫하니까 라는 이유로 불편함이 있더라도 React이외에 다른 것들은 시도조차 안해보시더군요. Angular는 뭔가 비대하고 배우기 어렵다는 편견이 있는데 실제로는 CLI로 쉽게 접근할 수 있고, 구조나 패턴도 스프링처럼 직관적이라 금방 배웁니다. 신입부터 시니어 개발자까지 초기에 몇 번의 스터디만으로 바로 프로젝트 투입도 가능했습니다. 백엔드 개발자도 금방 배워서 내부 운영툴도 쉽게 작성가능하고 프로젝트 규모가 커질 수록 프레임워크가 갖는 장점이 더 발휘됩니다. 또한 새로운 프로젝트를 하더라도 쉽게 빌딩이 가능하며 스프링처럼 외부 개발자가 오더라도 Angular 경험이 있다면 구조가 동일하니 쉽게 적응하실 수도 있구요. Angular는 정해진 로드맵에 따라 매년 2회 메이저 버전이 릴리즈 됩니다. 6월에 v14가 릴리즈 예정입니다. 메이저 버전이 올라가더라도 어떤 부분들이 변경되고 추가되었는지 한 눈에 볼 수 있는 버전별 비교 체크리스트도 친절하게 제공됩니다. 그 밖에도 기존 FE개발자 경험을 고려하여 프레임워크 구조를 이해하지 않았더라도 사용가능한 single-alone component 도 준비중이라고 합니다. 이 밖에도 최근 Angular 근황이 좀 더 궁금하시다면 얼마전 공개된 구글 IO에서 state of Angular 세션이 도움이 되실 겁니다.
지금은 리액트로 좀 통일되긴 했지만 여전히 변화속도가 빠른 자바스크립트 진영임을 생각해보면 상대적으로 유연하게 변화될 수 있는 리액트가 유리하지 않나 싶습니다. 새로운 기술이 나왔을 때 '마법같이' 어떤 처리를 대신해주는 프레임워크들보다 기본적으론 js 를 최대한 자유롭게 쓸 수 있는 게 리액트니까요. 예로 다른 분들도 언급하셨지만 타입스크립트라는 큰 흐름이 왔을 때 가장 빨리 적응할 수 있었던 것도 리액트였죠
비슷한 고민을 했었는데 주제로 다뤄주셔서 너무 좋아요! 그로 인해 관련 주제로 댓글들이 달리는 것도 너무 보기 즐겁네요. 앞으로도 FE 관련 컨텐츠가 많이 나오면 좋겠어요. ㅎㅎ 개인적으로는 현재 React 기반 FE 에서 구조, 테스트 관련 best practice 가 뾰족하게 없다고 생각합니다.
지극히 JAVA 및 JVM 언어와 OOP 페러다임에 익숙한 사람들의 영상이네요. 불만 보면 절반은 그냥 FE 쪽 경험과 실력이 떨어져서 그런거 같고, 멘탈 모델 자체가 OOP에 맞게 되어 있다보니 저렇게 생각하시는거 같네요. (물론 BE쪽 실력은 대단하십니다.) 그리고 나머지 절반 정도는 FE 개발자 입장에서도 느끼는 불만이긴 합니다. 타입스크립트는 JS에 타입을 강하게 해놓은 것이지 타입스크립트를 보고 OOP만을 생각하면 무식한 개발자라고 볼 수 있습니다. FE 에서 타입스트립트를 통해서 클래스라는 형의 정의를 interface, type 을 이용해서 정의합니다. 단위테스트는 어렵긴 합니다. + UI단 특성상 그렇게 어렵게 짠 테스트가 다음날 되면 UI 변경 때문에 엎어야 하는 경우도 자주 있구요. 백엔드에 비해서 수정 요구사항이 상당히 많고 자주 있습니다. 애초에 HTML + CSS 와 BOM, DOM 등의 브라우저 호스트 환경을 고려하면서도 인메모리 상태관리를 동시에 고려해야 하는 특성상 나타나는 특수성이 있는데, 그걸 BE 개발자 입장에선 매우 이해하기 힘든거 같았습니다. 지금까지 단 이러한 FE의 특성을 깊이있게 통찰하는 분을 딱 한분 봤습니다. 영상에서도 느끼지만 CSS에 대한 이야기는 없군요. 대충 라이브러리로 만든거겠죠. DOM, CSSOM에 대한 특성 + CSS와 UI 단 스타일링 + 유지보수성이 강한 UI 컴포넌트에 대한 설계 + 각각의 컴포넌트에서 일어나는 이벤트 핸들링 + 전역 상태 관리 + 컴포넌트당 지역 상태 관리 + 각 이벤트 서버 응답에 대한 상태 동기화 + 자주 변경되는 UI단 변경 요구사항 등등을 이해한 상태에서 이제 JS와 React에 대한 이해가 나아가야 한다고 봅니다. 아마 영원히 좁혀지지 않는 간극이 되지 않을까 합니다
Immutable, viewModal class 구현에서 작업을 해봤는데요 typescript를 사용하게되면 view modal class를 제작해서 사용하는게 linting쪽에서 많이 걸리기때문에 type은 거의 필수라고 볼수 있을것같아요. 코드 퀄리티는 viewModal class를 제작해서 만드는게 코드를 이해하긴 좋았던것 object를 수정하거나 추가 컴포넌트간의 연결을 해당 클래스를 통해 쉽게 진행 할 수 있었고 단점이라고 하면 백엔드를 동시에 봐야한다는 것이 단점이라고 할 수 있을것같고 state management를 사용해서 제작하게되면 미들웨어만 보고 정리할 수 있는 부분 페이지 단위로 state을 불러와서 적용할 수 있는부분이있어서 장점이라고 할 수 있겠네요 단점이라고 하면 prop과 component간의 연결 부분이 코드적으로 불필요한 부분이 많았던것 같아요. 프론트엔드 짜실때의 선택에 도움이 되길 바랍니다.
저는 거의 매일 리엑트를 쓰는 초보인데 여태까지 크래스를 딱 한번만 쓴 것 같아요. 개인적으로 클래스 장벽이 조금 높은 것 같아요. 새러운 프로젝트 만드려고 유튜브나 블로그 찾아보면 거의 다 function으로 나오는 것도 있고요. 물론 꼭 필요하면 클래스도 배울 생각인데 당장은 안 급하다는 생각이 드네요.
그리고 vue.js 는 3 나오면서 composition API 나오면서, 오히려 다양성이 사라진듯. 또한 과정을 살펴보면 3.0까지 가는 데, 시간이 너무 올라간 듯. 또한 어설프게 리엑트 따라가는 듯 해서 관심이 뚝 떨어진 듯. 마찬가지로 react도 그닥 맘에 들진 않는데, 국내는 항상 그렇지만, 하나에 몰빵 꽃히면, 그걸로 가는 듯한 느낌. (앵귤러랑 스벨트 관심 좀...)
순수 FP냐 아니면 어느정도 짬뽕하냐 뭐가 좋은지는 이야기 하긴 어렵지만, 순수 FP 관점에서 보면 아시다시피 스칼라 같은 언어는 이단이라고 생각 되는 것이 어느정도 납득은 되면서도 한편으로는 실제 FE 영어에서 그 중간을 오가는 사례도 많아 보이고, 생각보다 잘 돌아가는 것을 보면 이걸 너무 학문적(?) 접근한다기 보다 가독성 및 개발 편의성에서 괜찮다고 한다면 크게 문제되는 안는 듯. 다만, 나는 그래서 그 경계를 결정하는데 '왜 그런 선택을 했어' 만 적절히 설명히 되면 나쁘진 않을 듯.
클래스 방식 사용하면 훅을 사용하지 못해서요ㅠ 리액트에서 요즘 제일 핫한 라이브러리인 React Hook Form, SWR, React Query 같은것도 다 훅 기반 라이브러리라 함수형이 주류일 수 밖에 없는것 같아요 클래스형을 채택하게 되면 프론트의 모던한 기술 스택을 사용 못한다는 단점도 있는것 같습니다
frontend의 경우 상태를 항상 유지해야하는 부분이 Backend와 다르기 때문에 상태관리자를 따로 두는게 일반적이라고 생각합니다. backend의 경우 사용자 요청에 담긴 내용을 기반으로 비지니스 로직을 처리한다고 하면 FE는 사용자가 발생하는 이벤트 기반으로 기존 상태와 조합하여 처리해야하기 때문에 상태관리자를 두지 않으면 불편한 점들이 많이 생긴다고 생각해요.
리액트는 상태관리 등에서 immutability가 너무 중요하다보니 클래스 인스턴스를 안쓰게 되는 것 같네요. 클린 아키텍처적으로 생각하면 리액트나 뷰나 결국 프레젠테이션 레이어이기 때문에, 상태관리 및 상태에 따라 오는 연산들은 함수지향적으로 가고 그 외의 도메인 및 데이터 레이어에서는 클래스로 짜면 좋은 구조가 나올 것 같네요. oop의 장점과 fp의 장점을 고루 섞은게 제 생각엔 제일 좋을 듯 합니다
맞아 immutability, stateless 이게 핵심이지 testability의 문제는 아님 oop에서 그렇게 힘들게 aop(sepratation of concern)를 주장하는데, functional component는 그 자체로 immutable, stateless하게 aop를 실현하니까 편하지
그냥 취미로 코딩 하는데 구지 클래스로 짜야 되나 하는 생각이 더 큰거 같습니다 클래스는 뭔가 덕지 덕지 붙는게 많다고 해야되나 초심자 입장에서는 그렇습니다 꼭 Fp스타일을 좋아해서 그렇다기 보다 코드가 많아지는 클래스 스타일의 필요성을 느끼지 못해서 그런거 아닌가 싶습니다 그리고 자바 스크립트는 this 가 정말 거지 같이 되있습니다 어디서 호출 하면 윈도우 객체고 어디서 호출 하면 함수고 이런 일관성도 없다 보니 꺼려지게 되는거 같은
FE 라고 해서 백엔드랑 로직이 만드는 방법이 딱히 다르진 않습니다. 그냥 많은 예제가 그렇게 하지 않으니, 대부분 그렇게 잘안하는 것 같습니다만, 굳이 클래스로 작성해야 하는 가 하면 그건 아닌 듯 해요. 여기서 부턴 선택의 영역이지만, 대부분 그러지 않아도 잘 작성할 수 있고, 오히려 객체지향을 꺼리는 건 잘못된 설계가 되었을 때, 또는 요구사항이 크게 변경될 때 유연하지 않아요. (내가 폐쇠라고 생각 햇던 것이 사실은 그게 아니었어...느낌?) 저는 그런 부분에서 FP 기반을 선호합니다만, ( 뭐 그렇다고 React 한다고 FP가 잘 되는 건 아니지만, 오히려 React 예제 대로면 FP랑은 거리가 먼 듯.) 성능 보다는 FP 쪽이 더 편해서 그렇게 하는 듯.
@@devbadak 혹시 Typescript에서는 Discriminated Union(동의어: tagged union, sum type)을 쓰는 게 제일 자연스러워 보입니다만 data와 메소드를 같은 곳에서 관리하고 싶어서 data가 아닌 class 형태로 만들고 싶으신 것으로 이해하면 괜찮을지요? 그런데 생각해 보니 class 형태가 자연스럽다면 discriminated union 자체를 field로 갖는 class로 만들어도 괜찮지 않을까 싶은데 어떻게 생각하시나요?
리엑트 자체만 놓고 보면 수요가 많으니 커리어에 이점이 있는건 맞겠죠? 하지만 이런 심도 있는 고민은 프레임워크를 도구로하여 프로덕트를 개발하는 개발자로써 해볼만하다고 생각이드네요~ 저는 백엔드 개발자라 프론트엔드 생태계의 사정을 잘 모르는데, 그래서 더더욱 영상 내용이 공감이 가는거 같아용😁
두분은 angular 하셔야 겠네요. React, vue 가 인기 있는 이유은 쉬워서 이고 그래서 난개발이 됩니다. 객체지향은 수년의 경험이 필요하고 솔리드 원칙 같은 원칙에 따라야 합니다. 코드 컨벤션 수준이 높을수록 좋은 프레임워크 입니다. 그리고 객체지향 자체가 프론트를 위해서 나온거에요. 게임 같은 복잡한 오브젝트 관리는 객체지향이 아니면 개발 자체가 불가능 합니다. 결론은 객체지향으로 코딩 안하는것은 쉬운것만 만들기 때문입니다.
스마트기기. 안전하게 사용합시다. 좋은 습관을 만들어요. 장문이네요. ... 영상, 잘 봤습니다. 재미있네요. 리액트. npm으로 설치하고... 소스코드를 적으면 되죠. 웹프로그래밍이랑 마찬가지이구요. 리액트 문법이 있고, 리액트 관련책도 있어요. 리액트 프로그래밍 정석이라는 책이 있군요. 리액트 네이티브를 잘한다고 생각합니다. 리덕스를 사용할 때, 프론트엔드에 되먹임. 이런 부분이 있더군요. 리덕스보다, AsyncStorage를 사용하면 쉽구요. 리덕스 사용에 정형화. 그런 부분이 있더군요. 유데미보고 공부했었네요. 공부해보세요. 리덕스는 리액트에서 사용하는 모듈. 이렇게 생각하면 좋겠죠. 앱만들기 그런 부분인데... 정형화 형태로 보이더군요. 값 입력하는데도, 되먹임을 사용. 또 데이터 담기. 이런 부분도 있구요. 리액트네비게이션도 해야하는구나. 리액트네이티브로 앱을 만들려면, 리액트네비게이션을 쓰거나, 리액트네이티브로 웹앱으로 만들기. 웹앱을 만들어도 리액트네비게이션을 사용할 수도 있죠. 그냥 리액트네이티브로도 되구요. 리액트는 웹프로그래밍, 리액트네이티브가 앱프로그래밍. 이렇게 말할 수 있습니다. 리덕스나 리액트네비게이션. 모듈이라고 할 수 있겠죠. 리액트네이티브와 리액트. 이렇게 따로 생각해도 되구요. 문법은 비슷한것 같아요. 리덕스는 따로 리액트나 리액트네이티브 안에서 사용되구요. 웹앱 개발엔, 리액트 네이티브. 개발해보세요. 글을 적고 고치느라 헷갈릴 수도 있겠어요. 저의 깃헙도 있는데, 참조해보세요. 유데미도 보구요. 좋은 개발되세요. 또, 교회. 다녀보세요. 기독교. 전화도 해보세요. 사회에서 쉴 곳. 하고 싶은 말이네요. 좋은 하루되세요. 저의 댓글, 봐 주셔서 감사합니다.
우리때는 당연히 풀스택이었는데 요즘은 당연하게 프론트와 백을 나누는게 참 어색하네요. 이번에 처음으로 리액트 프로젝트를 했습니다. 너무 편하고 즐거웠던 개발이었는데요. 검색하면 쓰레기라고 제일먼저 나오는 넥사크로와 유사한 방향성이 있어서 개발에는 어려움이 없었네요. 저는 반대로 아직도 TDD가 이해가 안되네요. 목적이 뭔지 도무지... 오류날껄 알면 안나게 개발을 해야지
![[Full Episode] MasterChef Junior Thailand มาสเตอร์เชฟ จูเนียร์ ประเทศไทย Season 3 Episode 2](http://i.ytimg.com/vi/YpQnHoQvZt4/mqdefault.jpg)
백엔드만 한참 해온 개발자들이 프론트하면 항상 이렇게 생각하더라구요, 결국 잘 못한다는 뜻입니다. 백엔드한다고 프론트 못한다고 생각하진않는데 대부분 생각이 유연하지는 못하더라구요.
그리고 프론트에서 OOP안쓴다고 생각하는것도 되게 잘못된 방향으로 생각하는거같네요. 대부분 프론트개발자들이 수준미달이 많긴합니다만 OOP에서 중요하게 생각하는 SOLID원칙을 생각하지않고 좋은코드를 짤수가없습니다.
리액트가 함수컴포넌트라는 네이밍을써서 FP랑 되게 착각을 많이하던데 실제로는 컴포넌트 코딩하는 패턴이나 상태관리 도구 사용한는거보면 OOP에 가깝습니다...FP는 순수함수를 디폴트로 가져가는데 함수컴포넌트 개발할때 그런식으로 개발하지도않고 useEffect는 이름부터 사이드이펙트입니다...
아직 공부하는 학생 입장에서 찍어서 향만 맡아본 입장이라 많이 많이 부족한 점이 있을 수 있습니다.
그리고 제가 말하기에 지식이 부족한 React에 대한 내용보다는 함수형 프로그래밍에 초점을 맞추어 작성하였습니다.
혹시 틀린 내용 있으면 지적해 주시면 수정하도록 하겠습니다!
1. OOP와 FP의 관점 차이
개인적으로 OOP와 FP는 세상을 모델링하는 관점에 근본적인 차이가 있다고 생각합니다.
"객체지향의 사실과 오해"라는 책을 읽고 느낀 점은 OOP는 세상을 **여러 개의 서로 상호작용하는 독립적인 object들**(1)로 구성한다고 느꼈고, 인터넷 자료(2)들을 참고하면서 FP는 세상을 **불변하고 내부를 읽을 수 있는 data와, data를 순수 함수를 이용해 다른 data로 만들어주면서 만드는 unix pipe 같은 흐름**으로 구성한다고 느꼈습니다. (짧게 표현하다 보니 뉘앙스가 빠진 부분이 있을 것 같은데 지적해주시면 수정하겠습니다!)
그런 의미에서 OOP 전문가의 입장에서 FP를 보면 state를 관리를 안하면 그 state를 여러 곳에서 접근을 할 텐데 이걸 어떻게 관리하냐는 물음은 당연히 나올 수 있다고 생각합니다. 그리고 그에 대한 해답은 기본적으로는 변경가능한 state를 만드는 것이 아니라, 변경 불가능한 data를 이용해서 누가 접근하는지 자체를 신경쓰지 말게 하고, data는 한 가지 방향으로 흐르게 해서 각 지점에서의 상태를 파악할 수 있게 하는 것으로 저는 이해했습니다.
(1) 생각을 정리하여 수정중입니다.
(2) 이것저것 찾아보긴 하는데 대표적인 것으로 다음이 있습니다. F# 언어를 이용해 설명을 하는데 언어와 상관없이 도움이 되었던 것 같아요.
fsharpforfunandprofit.com/
2. 객체지향과 설계의 구분
개인적인 의견으로는 어떤 패러다임이든 일정 규모 이상의 프로젝트에서는 짜임새 있는 설계는 필요하다는 생각입니다.
그리고 SOLID design principle은 객체지향에만 쓸 수 있는 개념이 아닌, 함수형 패러다임에서도 언어가 지원해준다면 따르면 손해 안 보는 좋은 설계 원칙이라고 생각됩니다. 그리고 많은 함수형 언어에서 이미 SOLID에 대응되는 디자인 원칙이 정립되어 있는 것으로 알고 있습니다. 예를 들면 Interface 대신 함수 타입에 적절한 명세의 이름을 붙여준다면 같은 명세를 갖는 다양한 함수들로 구현을 교체할 수 있고, 함수를 parameter로 갖는 고차 함수를 통해 생성자 주입에 해당되는 Dependency injection을 수행할 수 있습니다.
따라서 프로그래밍 패러다임과 좋은 소프트웨어 설계는 X축과 Y축처럼 서로 독립적인 개념이 아닐까 싶은 생각이 듭니다. 객체지향적인 패러다임을 준수하면서 짜임새 있게 짤 수도 있고 막 짤 수도 있듯이, 함수형 패러다임을 가지고도 짜임새 있게 짤 수 있고 막 짤 수도 있다고 생각합니다.
따라서 저는 함수형 코드가 짜임새가 없다기보다는 객체지향이든 함수형이든 제대로 된 설계가 없는 코드가 짜임새 없는 것이 아닐까라고 생각하였습니다.
그리고 주제에 벗어나는 얘기지만 오해를 막기 위해 첨언하자면, 짜임새 없는 코드도 환경이 빨리 바뀌는 상황에서는 최선의 선택이 될 수도 있다고 생각합니다.
3. class-enum에 대한 기능을 Typescript에서는 tagged union으로 나타낼 수 있으며 compiler가 각 케이스별로 타입 추론도 해 주는 것으로 알고 있습니다. 혹시 이 부분에 부족함을 느끼셔서 라이브러리를 만드신 것인지요?
4. 좋은 Food for thought를 제공해주셔서 감사드리며, 당돌한 글 읽어주셔서 감사드립니다.
감탄했습니다. 학생이라고 하셨는데도 근본적인 부분에 훌륭한 통찰력을 갖고 계시네요. 현업이지만 배워갑니다. 1년 이상 늦게 댓글을 접하게 됐지만 감사합니다.
매번 고민하던 부분 중에 하나였는데, 호돌, 향로님도 같은 생각을 하고 계셨군요! 출근길에 좋은 컨텐츠 감사합니다 :)
두분 얘기하는거 듣다보면 무림 고수들의 비무를 보고 깨달음 얻는 하수 느낌이 드네요.. 단순히 강의보고 공부하는거 이상으로 뭐가 필요한지 몰랐는데 길을 찾아갈 지침이 되는거 같아 감사합니다
아직 전부 알아듣진 못하지만 용어들을 익히는데 도움이 될 것 같아서 늘 잘 챙겨보고 있어요! 오늘은 자막이 없어서 아쉽네요ㅜㅜ
출근길에 듣기 좋아요.
잘 볼께염~^^
취준생 때 프론트를 굉장히 얕게 공부하고 취업한 이후로는 회사에서 백엔드 개발만 하고 취미로만 프론트를 조금 다루고 있어서 프론트 쪽은 마땅히 물어볼 데도 없고 공부할 우선순위도 낮아 방치하고 있었는데요, 공식문서나 블로그에서 제대로 다뤄주지 않는 의문을 영상에서 제시해주시고 재야에 숨어있는 프론트 개발자분들이 달아주신 답변과 개인의견을 읽어보니 갖고 있던 의문이 많이 해소되고 생각이 좀 정리가 되네요. 생각지도 못한 좋은 주제 감사합니다.
저는 React의 JSX와 상태 관리에 불편함을 느끼고서 Angular로 넘어왔는데 현재도 정말 만족하며 쓰고 있습니다. 특히 Ivy 랜더링 엔진으로 변경된 이후 정말 빠르고 가벼워졌습니다. 아직도 과거 AngularJS 시절의 이미지를 그대로 갖고 계신 FE 개발자 분들도 계시는데 다시 한번 해보시길 권해드립니다.
다만 사내 React 개발자분들 얘기를 들어보면 그냥 대세니까 핫하니까 라는 이유로 불편함이 있더라도 React이외에 다른 것들은 시도조차 안해보시더군요.
Angular는 뭔가 비대하고 배우기 어렵다는 편견이 있는데 실제로는 CLI로 쉽게 접근할 수 있고, 구조나 패턴도 스프링처럼 직관적이라 금방 배웁니다. 신입부터 시니어 개발자까지 초기에 몇 번의 스터디만으로 바로 프로젝트 투입도 가능했습니다.
백엔드 개발자도 금방 배워서 내부 운영툴도 쉽게 작성가능하고 프로젝트 규모가 커질 수록 프레임워크가 갖는 장점이 더 발휘됩니다.
또한 새로운 프로젝트를 하더라도 쉽게 빌딩이 가능하며 스프링처럼 외부 개발자가 오더라도 Angular 경험이 있다면 구조가 동일하니 쉽게 적응하실 수도 있구요.
Angular는 정해진 로드맵에 따라 매년 2회 메이저 버전이 릴리즈 됩니다. 6월에 v14가 릴리즈 예정입니다. 메이저 버전이 올라가더라도 어떤 부분들이 변경되고 추가되었는지 한 눈에 볼 수 있는 버전별 비교 체크리스트도 친절하게 제공됩니다.
그 밖에도 기존 FE개발자 경험을 고려하여 프레임워크 구조를 이해하지 않았더라도 사용가능한 single-alone component 도 준비중이라고 합니다. 이 밖에도 최근 Angular 근황이 좀 더 궁금하시다면 얼마전 공개된 구글 IO에서 state of Angular 세션이 도움이 되실 겁니다.
리액트 개발자 찾는 회사가 많고 수요가 많아야 연봉도 높으니 리액트 하겠죠
리액트는 쓰레기
저도 react 쓰면쓸수록 제품 개발용으로는angular가 나은것같은데 시장이 너무 한쪽으로 확 간것같아서 좀 아쉽네요
지금은 리액트로 좀 통일되긴 했지만 여전히 변화속도가 빠른 자바스크립트 진영임을 생각해보면 상대적으로 유연하게 변화될 수 있는 리액트가 유리하지 않나 싶습니다. 새로운 기술이 나왔을 때 '마법같이' 어떤 처리를 대신해주는 프레임워크들보다 기본적으론 js 를 최대한 자유롭게 쓸 수 있는 게 리액트니까요. 예로 다른 분들도 언급하셨지만 타입스크립트라는 큰 흐름이 왔을 때 가장 빨리 적응할 수 있었던 것도 리액트였죠
비슷한 고민을 했었는데 주제로 다뤄주셔서 너무 좋아요! 그로 인해 관련 주제로 댓글들이 달리는 것도 너무 보기 즐겁네요. 앞으로도 FE 관련 컨텐츠가 많이 나오면 좋겠어요. ㅎㅎ
개인적으로는 현재 React 기반 FE 에서 구조, 테스트 관련 best practice 가 뾰족하게 없다고 생각합니다.
지극히 JAVA 및 JVM 언어와 OOP 페러다임에 익숙한 사람들의 영상이네요. 불만 보면 절반은 그냥 FE 쪽 경험과 실력이 떨어져서 그런거 같고, 멘탈 모델 자체가 OOP에 맞게 되어 있다보니 저렇게 생각하시는거 같네요. (물론 BE쪽 실력은 대단하십니다.) 그리고 나머지 절반 정도는 FE 개발자 입장에서도 느끼는 불만이긴 합니다.
타입스크립트는 JS에 타입을 강하게 해놓은 것이지 타입스크립트를 보고 OOP만을 생각하면 무식한 개발자라고 볼 수 있습니다. FE 에서 타입스트립트를 통해서 클래스라는 형의 정의를 interface, type 을 이용해서 정의합니다.
단위테스트는 어렵긴 합니다. + UI단 특성상 그렇게 어렵게 짠 테스트가 다음날 되면 UI 변경 때문에 엎어야 하는 경우도 자주 있구요. 백엔드에 비해서 수정 요구사항이 상당히 많고 자주 있습니다.
애초에 HTML + CSS 와 BOM, DOM 등의 브라우저 호스트 환경을 고려하면서도 인메모리 상태관리를 동시에 고려해야 하는 특성상 나타나는 특수성이 있는데, 그걸 BE 개발자 입장에선 매우 이해하기 힘든거 같았습니다. 지금까지 단 이러한 FE의 특성을 깊이있게 통찰하는 분을 딱 한분 봤습니다.
영상에서도 느끼지만 CSS에 대한 이야기는 없군요. 대충 라이브러리로 만든거겠죠.
DOM, CSSOM에 대한 특성 + CSS와 UI 단 스타일링 + 유지보수성이 강한 UI 컴포넌트에 대한 설계 + 각각의 컴포넌트에서 일어나는 이벤트 핸들링 + 전역 상태 관리 + 컴포넌트당 지역 상태 관리 + 각 이벤트 서버 응답에 대한 상태 동기화 + 자주 변경되는 UI단 변경 요구사항 등등을 이해한 상태에서 이제 JS와 React에 대한 이해가 나아가야 한다고 봅니다.
아마 영원히 좁혀지지 않는 간극이 되지 않을까 합니다
재밌네용ㅎㅎ 근데 bgm 소리가 너무 커서 목소리가 묻히네요ㅜㅜ
Immutable, viewModal class 구현에서 작업을 해봤는데요 typescript를 사용하게되면 view modal class를 제작해서 사용하는게 linting쪽에서 많이 걸리기때문에 type은 거의 필수라고 볼수 있을것같아요. 코드 퀄리티는 viewModal class를 제작해서 만드는게 코드를 이해하긴 좋았던것 object를 수정하거나 추가 컴포넌트간의 연결을 해당 클래스를 통해 쉽게 진행 할 수 있었고 단점이라고 하면 백엔드를 동시에 봐야한다는 것이 단점이라고 할 수 있을것같고 state management를 사용해서 제작하게되면 미들웨어만 보고 정리할 수 있는 부분 페이지 단위로 state을 불러와서 적용할 수 있는부분이있어서 장점이라고 할 수 있겠네요 단점이라고 하면 prop과 component간의 연결 부분이 코드적으로 불필요한 부분이 많았던것 같아요. 프론트엔드 짜실때의 선택에 도움이 되길 바랍니다.
이 정도면 거의 뷰에 중독 된거 아입니까
너무 공감되네요 ㅋㅋㅋㅋ
저는 거의 매일 리엑트를 쓰는 초보인데 여태까지 크래스를 딱 한번만 쓴 것 같아요. 개인적으로 클래스 장벽이 조금 높은 것 같아요. 새러운 프로젝트 만드려고 유튜브나 블로그 찾아보면 거의 다 function으로 나오는 것도 있고요. 물론 꼭 필요하면 클래스도 배울 생각인데 당장은 안 급하다는 생각이 드네요.
velopert님 초청해서 react 물어보고싶네요
vue로 시작했고 지금은 거의 react만 쓰고 있는데, vue나 react나 지금 그 자체로는 비슷하다고 생각합니다. 근데 다만 굳이 vue를 선택해야하는가 에 대해서 '굳이?' 라는 생각이 들 뿐 ㅎㅎㅎ
좋은 내용인데 제가 신입이어서 다 이해하지 못 해서 아쉽네요...이분들이 말하는 거 5년 지나면 공감할 수 있겠죠?
클래스스러운 상태관리 Mobx
다만, 순수 js객체가 아니라 직렬화하거나 할때 toJS 써야하고 그런게 있음
그리고 vue.js 는 3 나오면서 composition API 나오면서, 오히려 다양성이 사라진듯. 또한 과정을 살펴보면 3.0까지 가는 데, 시간이 너무 올라간 듯. 또한 어설프게 리엑트 따라가는 듯 해서 관심이 뚝 떨어진 듯. 마찬가지로 react도 그닥 맘에 들진 않는데, 국내는 항상 그렇지만, 하나에 몰빵 꽃히면, 그걸로 가는 듯한 느낌. (앵귤러랑 스벨트 관심 좀...)
저도 뷰 개발자 발언 이후로 갈아탔었는데.. 덕분에 취직이 수월했으니 고마워 했어야 했나 싶네요 ㅎㅎ 대부분의 개발자 및 코더에게 중요한 건 어차피 밥 빌어먹고 살 수 있느냐여서 ㅋㅋ
뷰 개발자 발언이 뭔가요?
@@user-wp6vu6tv5q 2019 홍콩 시위 때 "자유, 얼마나 많은 죄악이 네 이름을 빌렸나" 란 트윗을 올려 중국을 옹호했었죠
@@tw04 헐ㅋㅋ 그런 일이 있었군요
순수 FP냐 아니면 어느정도 짬뽕하냐 뭐가 좋은지는 이야기 하긴 어렵지만, 순수 FP 관점에서 보면 아시다시피 스칼라 같은 언어는 이단이라고 생각 되는 것이 어느정도 납득은 되면서도 한편으로는 실제 FE 영어에서 그 중간을 오가는 사례도 많아 보이고, 생각보다 잘 돌아가는 것을 보면 이걸 너무 학문적(?) 접근한다기 보다 가독성 및 개발 편의성에서 괜찮다고 한다면 크게 문제되는 안는 듯. 다만, 나는 그래서 그 경계를 결정하는데 '왜 그런 선택을 했어' 만 적절히 설명히 되면 나쁘진 않을 듯.
와.. 생계 유지를 위해 리액트, RN을 하고 있는데 이런 의문을 다수가 가질수있게 비슷한 영상이 많이 올라왔으면 좋겠어요.
파란색이 좋다 : 리액트
초록색이 좋다 : 뷰
후다닥 달려왔습니다 ㅎㅎ
flutter + bloc + 클린아키텍처 짱
9:32 이부분은 항상 개발자들끼리 술마시면 토론하는 이슈인듯
저같은 경우는 리액트 에 비해서 뷰가 배울게 너무 많아서 리액트로 넘어간 케이스네여
뷰 쓰다가 리액트 코드를 처음 봤을때
눈에 확실히 익어서 좋았던 것 같아요.
vue를 계속 다시 해보려고 하는데
마법(?) 같은 코드때문에 계속 리액트로 돌아가게 되는 듯 합니다
이런 곡예 비행이 재밌네요 ㅋㅋㅋㅋㅋ
28:50 이부분에서 저도 그 이유가 너무 궁금하더라구요.
제 개인적인 생각으로는 syntax가 간단해서 빠르게 만들기 편해서 그렇지 않을까 싶네요.
아무리 생각해도 규모가 커질수록 angular나 vue가 낫다고 생각이 들어서요
프론트 개발자 분과 함께하는 편이 기대됩니다.
클래스 방식 사용하면 훅을 사용하지 못해서요ㅠ 리액트에서 요즘 제일 핫한 라이브러리인 React Hook Form, SWR, React Query 같은것도 다 훅 기반 라이브러리라 함수형이 주류일 수 밖에 없는것 같아요
클래스형을 채택하게 되면 프론트의 모던한 기술 스택을 사용 못한다는 단점도 있는것 같습니다
앵귤러를 쓰시면 될거같은데요?
저도 느끼는 점은 규모에 대한 문제점은 사실 진짜 애매한거 같습니다.
vue UP! 👍
frontend의 경우 상태를 항상 유지해야하는 부분이 Backend와 다르기 때문에 상태관리자를 따로 두는게 일반적이라고 생각합니다. backend의 경우 사용자 요청에 담긴 내용을 기반으로 비지니스 로직을 처리한다고 하면 FE는 사용자가 발생하는 이벤트 기반으로 기존 상태와 조합하여 처리해야하기 때문에 상태관리자를 두지 않으면 불편한 점들이 많이 생긴다고 생각해요.
리액트는 상태관리 등에서 immutability가 너무 중요하다보니 클래스 인스턴스를 안쓰게 되는 것 같네요. 클린 아키텍처적으로 생각하면 리액트나 뷰나 결국 프레젠테이션 레이어이기 때문에, 상태관리 및 상태에 따라 오는 연산들은 함수지향적으로 가고 그 외의 도메인 및 데이터 레이어에서는 클래스로 짜면 좋은 구조가 나올 것 같네요. oop의 장점과 fp의 장점을 고루 섞은게 제 생각엔 제일 좋을 듯 합니다
실제로 저는 리액트+mobx 쓰는데요 말씀하신대로 데이터쪽은 클래스로 만들고 컴포넌트 쪽은 함수형으로 만들어서 프로젝트 3개정도했거든요 정말 만족스러웠습니다
맞아 immutability, stateless 이게 핵심이지 testability의 문제는 아님
oop에서 그렇게 힘들게 aop(sepratation of concern)를 주장하는데, functional component는 그 자체로 immutable, stateless하게 aop를 실현하니까 편하지
굳굳 👍👍
21:24 👍
자바 스프링이 타 백엔드 언어보다 장점인 점은 무엇일까요? 규모가 큰 IT기업들은 거의 무조건 자바 스프링인데 비슷한 의문이 들었네요
자바 스프링의 장점이라면,
20년이 넘는 세월 동안 백엔드 시장을 독점하다시피 지배하면서 겪어야 했던 수많은 상황들과 이를 해결하면서 쌓여진 경험치?
경력자가 많다는 거죠. 인력 문제
@@SeonYeongMaeng 그건 언어 자체의 장점이라기보단 시장에서의 유용함정도가 아닐까요? 본영상에선 언어자체의 불편함, 유용성을 다루고계셨던것 같아서요
본 영상에선 자바 스프링 이야기가 안 나오는데요?
@@kiakia1985 리액트 얘기처럼 자바스프링에 대해서도 궁금증이 들어서요 ㅎㅎ
진료는 의사에게
약은 약사에게
백엔드는 백엔드 개발자에게
프론트는 프론트 개발자에게
원래 클라이언트가 더럽습니다.
31:35 타이밍 무엇? ㅋㅋㅋㅋㅋ
그냥 취미로 코딩 하는데 구지 클래스로 짜야 되나 하는 생각이 더 큰거 같습니다 클래스는 뭔가 덕지 덕지 붙는게 많다고 해야되나 초심자 입장에서는 그렇습니다 꼭 Fp스타일을 좋아해서 그렇다기 보다 코드가 많아지는 클래스 스타일의 필요성을 느끼지 못해서 그런거 아닌가 싶습니다
그리고 자바 스크립트는 this 가 정말 거지 같이 되있습니다 어디서 호출 하면 윈도우 객체고 어디서 호출 하면 함수고 이런 일관성도 없다 보니
꺼려지게 되는거 같은
FE 라고 해서 백엔드랑 로직이 만드는 방법이 딱히 다르진 않습니다. 그냥 많은 예제가 그렇게 하지 않으니, 대부분 그렇게 잘안하는 것 같습니다만, 굳이 클래스로 작성해야 하는 가 하면 그건 아닌 듯 해요. 여기서 부턴 선택의 영역이지만, 대부분 그러지 않아도 잘 작성할 수 있고, 오히려 객체지향을 꺼리는 건 잘못된 설계가 되었을 때, 또는 요구사항이 크게 변경될 때 유연하지 않아요. (내가 폐쇠라고 생각 햇던 것이 사실은 그게 아니었어...느낌?) 저는 그런 부분에서 FP 기반을 선호합니다만, ( 뭐 그렇다고 React 한다고 FP가 잘 되는 건 아니지만, 오히려 React 예제 대로면 FP랑은 거리가 먼 듯.) 성능 보다는 FP 쪽이 더 편해서 그렇게 하는 듯.
Vue는 타입스크립트 호환이 잘 안되나요?
vue3부턴 기본 탑재 같아요
뷰가 쇠퇴하게 된것도 Vue3는 시기가 늦게 나오는데 Vue2는 타입스크립트 지원이 잘 안되고 프론트는 이미 타입스크립트 사용이 주류가 되었고 이런 문제가 있었던것도 꽤 큰거 같습니다
호도루쟝 ㅠㅠ
react 공부 중이라 타이틀보고 달려옴 휴…
제가 영상을 봐도 repo를 봐도 ClassEnum이 왜 필요한지 모르겠는데 .. 좀 더 쉽게 설명해줄 수 있을까요??
Enum을 왜 확장해야하는지 모르겠네요ㅜ
이 글을 참고해보시면 도움 되실 것 같습니다.
techblog.woowahan.com/2527/
@@devbadak 와우.. 이해완료했습니닷..
@@devbadak 혹시 Typescript에서는 Discriminated Union(동의어: tagged union, sum type)을 쓰는 게 제일 자연스러워 보입니다만 data와 메소드를 같은 곳에서 관리하고 싶어서 data가 아닌 class 형태로 만들고 싶으신 것으로 이해하면 괜찮을지요? 그런데 생각해 보니 class 형태가 자연스럽다면 discriminated union 자체를 field로 갖는 class로 만들어도 괜찮지 않을까 싶은데 어떻게 생각하시나요?
31:30에 같이 의자 고쳐앉으시는거 타이밍ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
개발바닥 특) 신입 개발자가 면접 매운맛으로 보기 좋음. 막 혼나고 이런게 아니라 기술 예기 어느정도까지 할 수 있나 알 수 있음
리액트 책샀는데 이럴수가 ㅋㅋ
OOP 와 FP 의 충돌 ㅋㅋ
선댓후감
속시원하네요 다 똑같은 느낌이네요
31:35 ㅋㅋㅋㅋㅋㅋ
vue3 랑 ts 같이 사용하는건 괜찮나요 ? 다른분들의 의견이 궁금합니다.
백엔드하다가 뷰쓰면그냥신세계든데 이런것도 있구나하고
아니 왜 속시원하게 말을 안해주시나요!
oop가 짱이야
전 주니어라 잘 모르겠지만, 무려 페북이 관리하는 라이브러리에다가 사라지지 않을것 같은 느낌도 주고 자료도 많고 이용자도 많으니 취업 이직에도 좋지 않나요
리엑트 자체만 놓고 보면 수요가 많으니 커리어에 이점이 있는건 맞겠죠? 하지만 이런 심도 있는 고민은 프레임워크를 도구로하여 프로덕트를 개발하는 개발자로써 해볼만하다고 생각이드네요~
저는 백엔드 개발자라 프론트엔드 생태계의 사정을 잘 모르는데, 그래서 더더욱 영상 내용이 공감이 가는거 같아용😁
그리고 사람들이 리엑트를 좋아하는 이유는 제 생각엔 쉽다는 것과 뭔가 많은 자유를 주면서 강력한 듯한 느낌을 주니까?? 그러고 보면 제이쿼리가 비슷한 이유지 않았을 까 싶은데,
두분은 angular 하셔야 겠네요. React, vue 가 인기 있는 이유은 쉬워서 이고 그래서 난개발이 됩니다. 객체지향은 수년의 경험이 필요하고 솔리드 원칙 같은 원칙에 따라야 합니다. 코드 컨벤션 수준이 높을수록 좋은 프레임워크 입니다. 그리고 객체지향 자체가 프론트를 위해서 나온거에요. 게임 같은 복잡한 오브젝트 관리는 객체지향이 아니면 개발 자체가 불가능 합니다. 결론은 객체지향으로 코딩 안하는것은 쉬운것만 만들기 때문입니다.
참고로 앵귤로는 증분형 돔을 사용합니다. 성능 생각하면 무조건 앵귤러 입니다.
ㅋㅋㅋㅋㅋㅋ백분들은 리액트를 혐오하시더라고요
편견입니다 저도 백인데 리액트 선호해요
oop 극혐..
Angular는요!?!
요약: 난 틀딱이고 java원툴이고 oop가 진리인 레거시 땔깜인데 fp랑 노드가 이렇게 뜰줄은 몰랐다 ㅜㅜ
class보다 hooks가 재 사용성이 좋습니다.
그냥 백엔드나 계속해야겠다
요점 28:00
oop 모르는 백엔드도 수두룩하긴함
th-cam.com/video/JUuic7mEs-s/w-d-xo.html 이런것도 있어요!
스마트기기. 안전하게 사용합시다. 좋은 습관을 만들어요.
장문이네요. ...
영상, 잘 봤습니다. 재미있네요.
리액트. npm으로 설치하고... 소스코드를 적으면 되죠.
웹프로그래밍이랑 마찬가지이구요. 리액트 문법이 있고, 리액트 관련책도 있어요. 리액트 프로그래밍 정석이라는 책이 있군요.
리액트 네이티브를 잘한다고 생각합니다. 리덕스를 사용할 때, 프론트엔드에 되먹임. 이런 부분이 있더군요. 리덕스보다, AsyncStorage를 사용하면 쉽구요.
리덕스 사용에 정형화. 그런 부분이 있더군요. 유데미보고 공부했었네요. 공부해보세요. 리덕스는 리액트에서 사용하는 모듈. 이렇게 생각하면 좋겠죠.
앱만들기 그런 부분인데... 정형화 형태로 보이더군요. 값 입력하는데도, 되먹임을 사용. 또 데이터 담기. 이런 부분도 있구요. 리액트네비게이션도 해야하는구나.
리액트네이티브로 앱을 만들려면, 리액트네비게이션을 쓰거나, 리액트네이티브로 웹앱으로 만들기. 웹앱을 만들어도 리액트네비게이션을 사용할 수도 있죠.
그냥 리액트네이티브로도 되구요.
리액트는 웹프로그래밍, 리액트네이티브가 앱프로그래밍. 이렇게 말할 수 있습니다. 리덕스나 리액트네비게이션. 모듈이라고 할 수 있겠죠.
리액트네이티브와 리액트. 이렇게 따로 생각해도 되구요. 문법은 비슷한것 같아요. 리덕스는 따로 리액트나 리액트네이티브 안에서 사용되구요.
웹앱 개발엔, 리액트 네이티브. 개발해보세요. 글을 적고 고치느라 헷갈릴 수도 있겠어요.
저의 깃헙도 있는데, 참조해보세요. 유데미도 보구요. 좋은 개발되세요.
또, 교회. 다녀보세요. 기독교. 전화도 해보세요. 사회에서 쉴 곳. 하고 싶은 말이네요.
좋은 하루되세요.
저의 댓글, 봐 주셔서 감사합니다.
우리때는 당연히 풀스택이었는데 요즘은 당연하게 프론트와 백을 나누는게 참 어색하네요. 이번에 처음으로 리액트 프로젝트를 했습니다. 너무 편하고 즐거웠던 개발이었는데요. 검색하면 쓰레기라고 제일먼저 나오는 넥사크로와 유사한 방향성이 있어서 개발에는 어려움이 없었네요. 저는 반대로 아직도 TDD가 이해가 안되네요. 목적이 뭔지 도무지... 오류날껄 알면 안나게 개발을 해야지
삼성그룹 프로젝트 -> VUEJS