리액트를 명령형으로 짜면 안되는 이유? 예시코드로 알아보자! (+ 선언적 코드로 리팩토링 해보기)
Vložit
- čas přidán 13. 09. 2024
- 안녕하세요 오늘은 리액트를 사용할 때 선언적 프로그래밍으로 구현한다는 의미가 무엇인지, 명령형으로 구현한 예시코드와 비교하여 알아보았습니다. 기술을 제대로 사용하기 위해서는 그 기술의 배경과 철학을 이해하는 것이 도움이 되는 것 같아요. 깊이 있게 공부하며 한걸음 더 성장하는 우리 모두가 되길 응원합니다.
그럼 오늘도 퐈이팅입니다 :)
useUsers에 try catch로 api call에 실패한 경우 error를 지정하고 리턴해주는데
api call에서 에러가 발생한 경우와 하위 컴포넌트에서 발생한 에러를 따로 처리해주는 셈이지 않나요?
UserList 컴포넌트에서 error이 지정되면 error를 렌더하던데 이러면 이중처리인 셈이 아닌가 싶어서요
맞습니다.
에러 처리에서,
제가 명령형과 선언적인 코드를 함께 사용한 부분이 있네요..!
말씀해주셔서 감사합니다!
말씀해주신 것중에
명령형으로 에러를 처리한 부분은
UserList 컴포넌트에서 직접 에러를 렌더하는 부분입니다.
(try catch 로 api call 에 실패한 경우, error 를 지정하고 리턴해주는 부분 포함)
선언적으로 에러를 처리한 부분은
ErrorBoundary 로 에러를 처리한 부분입니다.
다시한번 정확한 정보를 전달하도록 도와주셔서 감사합니다.
리액트의 선언형 철학에 대해 다시 한 번 리마인드 하게 되네용. 물론 실제 개발할 땐 유연한 접근이 필요하겠지만, 상황에 따라 균형있게 사용하는 것이 국룰아닐까여 흐흐
매번 너무좋은 영상 올려주셔서 감사합니다 최고입니다
항상 봐주셔서 감사합니다!
설명 너무 이해하기 쉽게 잘 해주시네요
잘봤습니다
도움이 되셨다니 감사합니다
실무하면서 고민하던 부분인데 좋은 가이드가 될 것 같네요 감사합니다.
도움이 되셨다니 다행입니다.
좋은 리펙토링 팁을 얻었습니다. 감사합니다
도움이 되셨다니 다행입니다.
좋은 영상 잘봤습니다:)
봐주셔서 감사합니다!
선언적 프로그래밍으로 구현하는 것에 대해 항상 고민이 많았는데, 예시를 들어주셔서 쉽게 이해가 되었습니다! 😊혹시 유튜브 내용을 블로그에 공부 차원에서 올리고 싶은데 괜찮을까요?
출처만 밝혀주시면 괜찮습니다 :)
크 너무 맛있네요 결과적으로 그냥 똑같다고 하는사람은 도대체 영상을 뭘로 본건지 싶네요 너무 잘봤습니다
좋은 영상 감사합니다
시청해 주셔서 감사드립니다.
지금 저희 팀에서 특정 기능을 모듈화 하고 있는데,
React는 View 역할만 담당하게 하고 나머지 기능 로직은 class 로 구현하는 방향으로 설계가 진행되고 있습니다.
위와 같이 설계가 진행되는 이유는 기능이 React 프레임워크에 종속되지 않고,
바닐라, Vue, Angular 등 어디든 View만 교체하면 재활용할 수 있도록 하기 위함인데요
이렇게 React 를 활용해본 적이 없어서 이게 맞는 것인지 계속 고민이 되고 있는 상황입니다
(아이디어 및 설계 초안은 시니어 개발자 분이 해주셨는데, 풀스택이시지만 프론트는 제이쿼리 등 다소 레거시 툴을 많이 활용하셨던 편이라 React 경험은 크지 않으십니다)
개인적으로는 제가 좋아하는 코딩 스타일이라 (UI와 기능을 완벽히 분리하고, 기능 단 역시 관심사 분리 및 아토믹적으로 구현하는 것)
흥미가 있기는 하나 React에서 이러한 방식을 활용하는 것이 좋은 것인지는 계속 의문인 상황입니다.
본 동영상에서 설명해주신 바에 비추어보면
커스텀 훅 등의 선언적 방법이 아닌 클래스를 통해 생성한 인스턴스를 React 내부적으로 활용한다는 점에서
명령형 코드로 비추어지는 면이 있다고 생각되는데
혹시 어떻게 생각하시는지 의견을 여쭤보고 싶습니다.
(저도 아직 저희 팀 방향성에 대한 이해도가 높지 않아서 글이 다소 장황하네요 ^^:;;)
@rebornive 우선 너무 잘 설명해주셔서 상황 이해가 갔어요.
+ 제 동영상 제목이 약간의 어그로성 제목이어서 죄송합니다..ㅎㅎ
React 를 활용하는 방법에는 단 하나의 정답이 있는 것은 아닙니다.
팀의 상황과, 비즈니스 상황 등에 따라서 다양한 정답이 있을 수 있어서요.
말씀하신 Class 를 활용하여 비즈니스 로직을 분리하는 방식 또한 정답이 될 수 있어요.
flutter 진영에는 bloc 라는 디자인 패턴이 있는데요,
아래 보시면 이 bloc 를 리액트에 적용한 사례를 설명하고 있어요
github.com/sbyeol3/articles/issues/15
즉, 말씀해주신 Class 를 활용하여 비즈니스 로직을 분리하는 방식도
이미 하나의 정답으로 사용하고 있는 패턴이어서요.
다만, React 를 사용하다보면
비즈니스 로직과 뷰 로직을 결합해서 사용하게 되는 순간들이 찾아오기도 해요.
그렇게 짜는게 더 재사용성을 높여줄 때가 있어서요..!
뷰를 완전히 분리했을 때의 장점을 위해 이런 부분들을 적절히 포기하는 트레이드 오프는
충분히 가능하고 유익하다고 생각해요!
오 무쳐따 왜케 잘함
ㅎㅎ칭찬해주셔서 감사합니다 :)
만약 useUsers같은 커스텀 훅이 두 번 이상 쓰이지 않는다면 기존의 명령형 로직으로 사용해도 되는걸까요? 지금까지커스텀 훅은 재사용을 위해 사용한다는 느낌이 강했거든요!
커스텀훅으로 분리하는 이유는 재사용을 위해서도 있지만,
가독성을 위해서도 있어서요..!
예를 들어 useUsers 보다는 좀더 구체적으로
useUserManipulation 같은 이름으로 묶는다면
이 컴포넌트에서는 어떤 기능들이 필요하겠구나
훅 이름만 봐도 알 수 있어서요
(자세하게 기능에 대해 알고 싶으면
훅이 선언된 곳으로 가서 확인 해야겠지만요)
다만, 언제나 훅을 사용하는 것이 반드시 정답은 아니어요~!
말씀하신대로 재사용을 하지 않고,
기존에 로직이 그렇게 길지 않다면(길이는 주관적인 판단이 필요한 부분이라 팀내 합의가 되면 좋겠네요 ㅎㅎ)
훅으로 분리하지 않고, 컴포넌트 내에서 함께 선언하는 것이
가독성이 더 좋을 수도 있어요..!
이거 좋아보이는데 일부 소스는 유지보수가 까다로울것 같아요.
동의합니다.. 컴포넌트를 너무잘게 쪼개는 것도 때로는 유지보수를 어렵게 만들기도 하더라구요..!
결과적으로 둘이 똑같네용. 그리고 이거 선언적으로 작성하셨다고 하신 부분이 보기에는 좋고 뿌듯하긴한데, 구조가 복잡해지면 역으로 개발기간과 유지보수가 헬로 들어가는 경우가 많아여. 때문에 기능이 반복되는 경우만 이렇게 짜고, 반복되지 않는 경우는 그냥 명령형으로 짜는게 오히려 개발에 용이해요.
개발에 용이하다는게 무슨 뜻일까요? 누군가 코드를 다시 본다고 생각하고 작성해야 유지보수와 개발기간이 간편해지고 단축됩니다. 선언형으로 작성한다고 시간 크게 더 안들어요. 프로토타이핑?만 해보셨거나 흔한 SI에 있는 코드 대충 짜고 빠지고 기술부채 떠넘기는 실력 떨어지는 개발자가 아니라면 구조적으로 잘 설계하고 작성할 것이고 그렇게 되어 있는게 웬만한 개발자들도 보기 편할겁니다.
저도 댓글 의견에 공감하는 부분이 있습니다.
구조가 복잡해지면 구성원 모두가 복잡한 구조를 이해해야 하기 때문에,
너무 컴포넌트를 잘게 쪼개면, 그리고 선언적으로 추상화해서 구현하면 오히려 유지보수가 어려워질 때도 있더라구요.(실제로 현업에서는 무조건적인 공통화가 좋지 않게 작용한 경험도 있었어요)
또한 대댓글의 의견에도 공감하는 부분이 있습니다.
구조적으로 정말 잘 설계한다면 복잡해질 수는 있어도 이해하기 좀 더 수월해질 수 있을것 같습니다.
복잡 해진다는 것은 규모가 커질때 필연적인 결과라고도 생각해서요 그정도의 복잡함은 생기지만, 잘 설계하면 구조를 이해하기는 더 쉬워질것 같아요~!
@@user-tk9uj2sn7w이 말씀에 격하게 공감합니다.
선언형 프로그래밍 사용함에 있어 눈에 더 확실히 들어오고 가독성 있는 컴포넌트 구조가 보이는게 장점이라고 생각되네요.
선언형이 유지보수에 어렵다라는건 여태 마구잡이식으로 별 생각없이 관리 해왔다라는거 밖에 생각이 안드네요.
그거 실탄이 아니라 공포탄일 수도 있어요
항상상식선에서개발하면됨
한줄코드 일일이 함수분리해서짜면 보는사람열불남
반대로 다갖다넣는경우도그렇고
다 적당하고 심플하게
선언적 프로그래밍을 이해하시는데 노력은 하셨는데
명령적 프로그래밍을 모르시네요
전자는 명령적 프로그래밍 보다는
그냥 가독성이 떨어지는 엉망인 코드입니다
충분히 가독성이 떨어지는 엉망인 코드라고 보실수 있을것 같아요..!
예시코드가 정확히 명령형 프로그래밍과 일치하진 않지만, 리액트 안티패턴을 코드레벨에서 보여주고자 맥락상 명령형이라고 말한 점 양해 부탁드립니다..!
혹시 더 적합한 예시 코드를 알려주신다면 설명을 보완하는데 큰 도움이 될것 같아요 🙏