얍얍얍
531
2020-12-08 14:01:39 작성 2020-12-08 14:02:15 수정됨
21
1008

리액트 고수님들 redux에 관해 질문있습니다




여기서 mapDispatchToProps 안에 onAdd와 onDelete라는 key가 있잔아요. 제가 생각하기에는 return으로 객체를 store에 넘겨주는거 같은데 이걸 스토어는 어떻게 객체로 받는것인지 이해가 안갑니다. 제가 아래는 제가 만든 스토어 입니다.




0
  • 답변 21

  • ISA
    5k
    2020-12-08 14:21:02

    구조가 개판인거 같네요.

    특정 구조의 객체를 디스패치 하면 정의해둔 리듀서에서 그걸 처리합니다.

    mapDispatchToProps

    이건 디스패치 함수를 만들어서 컴포넌트의

    Props에 주는거지 스토어에 주는게 아닙니다.

    커넥트로 연결하면 해당 객체들을 해당 컴포넌트 props로 주는겁니다.

  • 숨쉬는조약돌
    299
    2020-12-08 14:28:07 작성 2020-12-08 14:29:19 수정됨

    답변을 달려고 했는데 윗분이 이미 답변 주셨네요. 

    말씀하신대로 dispatchToProps 은 component의 Props으로 전달되는 겁니다.

    그걸 받아서 처리하는 리듀서 및 기타 리듀서들을 모아서(saga 나 thunk 같은 비동기 처리를 위한 middleware도 사용하시고) store로 만들면 되는 것이고요. 


  • 얍얍얍
    531
    2020-12-08 14:34:21

    @candy 


    mapStateProps 도 그렇고 dispatchToProps 도 그렇고 둘다 props로 보내주잔아요 


    차이점이 있나요??
     




  • ISA
    5k
    2020-12-08 14:43:23

    그냥 리액트는 커녕 js 기본기도 부실하다고 보이는데... 개판이라는 말이 기분 나빴는지 답변한거 무시하는거 잘보았습니다. 따로 더 조언 드릴건 없고 비추나 드릴게요.

  • 페코옹
    1k
    2020-12-08 14:54:47 작성 2020-12-08 14:56:00 수정됨

    딱히 구조가 개판인건 아닌거 같은데요

    그냥 굉장히 기본적인 리덕스 예제인데 counter 예제에 todo 라고 명명한게 문제긴 하네요 ㅋㅋ


    connect함수에서  mapStateToProps, mapDispatchToProps 두 함수를 받아 컴포넌트의 props으로 주입 하는 방식으로 (이름 보면 아주 명확하죠? state와 dispatch를 props에 매핑시킨다.)

    과거 class 기반 컴포넌트에서는 위와 같은 hoc를 활용해서 컴포넌트의 props에 redux 의 state와 dispatch를 주입해주었고 

    요즘 hook 기반 컴포넌트에서는 useSelector, useDispatch를 이용해서 컴포넌트 안에서 state와 dispatch에 접근할 수 있어요.


    암튼 컴포넌트에서 redux의 state와 dispatch에 접근하는 방법이라고 생각하시면 됩니다


  • 숨쉬는조약돌
    299
    2020-12-08 15:02:20 작성 2020-12-08 15:04:35 수정됨

    stateToProps은 말 그대로 상태의 정보를 컴포넌트로 보내는 겁니다. 현재 로그인한 유저 정보라든지, 네비게이션 같은 거요. 

    dispatchToProps은 dispatch를 프롭으로 보내서 받아오는 컴포넌트에서 그때 그때 액션함수를 사용할 수 있게 해주죠. dispatch를 사용할 수 있게 되니 받아온 컴포넌트에서 액션함수 타입에 따라 상태를 바꾸실 수 있게 되는 거지요.


    그러니까 전자는 고정된 상태 정보 자체를 프롭으로 가져오는 것이고, 

    후자는 컴포넌트에서 상태를 변화시킬 수 있는 디스패치를 프롭으로 가져오는 겁니다. 

     

  • 얍얍얍
    531
    2020-12-08 15:05:20

    @ISA


    구조가 개판인건 맞네요 쩝 ㅋ;;


    혹시 return 때문에 그런것인지 보기 불편했다면 수정하겠습니다 ㅎ


    딱히 기분나쁘지도 않았고 오히려 답변해주셔서 감사합니다 

  • ISA
    5k
    2020-12-08 15:05:47

    페코옹 //

    코드가 잘못된거야 말할 필요도 없고 기본적인 권장사항들 안 지킨 구조라 개판이라 표현했습니다.

    액션을 분리 하지도 않아서 payload 보일러 플레이트로 처리는 커녕 그냥 생으로 타입과 상태를 주입 리듀서는 추후에 확장성은 커녕 기본적인 상태 관리조차 하드 코딩했죠. ConfigureStore같은 설계야 개인 자유지만 공식 문서나 기타 학습 자료에서 기초적으로 권장하는 요소들도 안지킨 코드로 보입니다.

  • 숨쉬는조약돌
    299
    2020-12-08 15:09:23

    투두리스트 하시는 걸 보니 아직 비기너셔서 그런거 같아요. 리덕스 부분이 어렵죠. 하지만 계속 하다보면 이해가 되는 순간이 옵니다. 

    화이팅하세요 

  • 페코옹
    1k
    2020-12-08 15:19:02

    리덕스 개발팀에서 리덕스 사용하는데 설정도 복잡하고 보일러플레이트 코드들도 많아지고 해서

    공식 리덕스를 쉽게 사용하는 라이브러리까지 만들었어요

    @redux/tookit 이라고..

    리덕스를 필요에 따라 적절하게 잘 사용하는게 중요한거 아니겠습니까? ㅎㅎ


  • 페코옹
    1k
    2020-12-08 15:21:14

    전 요즘 아예 리덕스 자체도 싫어져서 걍 context api 랑 swr 사용하고 있는데 암이 나았어요 ㅋㅋ


  • ISA
    5k
    2020-12-08 15:27:04

    페코옹 //

    커스텀 훅이랑 하드코딩이 같을 수는 없죠.

    툴킷 조차 기초적인 내용은 지키는 방식인데 뭘 말하시는지 모르겠네요.

    개발에서 생산성을 중시하는 입장이라 하더라도 기본적인 것을 안하는 걸 적절하게 잘 사용한다고 하지는 않지 않습니까? 

    무엇이 복잡하다는지는 솔직히 잘모르겠지만 개인적으로 초보일때 버릇을 잘 들이는게 좋다고 생각합니다. 

    선택 사항인 것과 막 짜는건 다르니까요.

  • 페코옹
    1k
    2020-12-08 15:28:35

    언어를 뭘쓰고 리덕스고 자시고 이런것들은 결국 내가 원하는  어플리케이션 만들기 위한 툴 아니겠습니까?

    젓가락질 못한다고 밥 잘 못먹는것도 아니구요


    바닐라, 앵귤러, 리액트, 뷰, 스벨트, 제이쿼리 어떤걸 쓰든 원하는 결과만 나오면 되고

    리덕스, 몹엑스, context를 뭘 쓰든 어플만 잘 만들면 되고

    액션을 따로 분리하든 그냥 dispatch에 쓰든 어플만 잘 만들면 되는거 아니겠습니까~~

  • ISA
    5k
    2020-12-08 15:28:47

    페코옹//

    저도 리액트 자체에서 리덕스와 비슷한 상태관리를 제공하려고 노력하는 건 긍정적이라 생각합니다. 아직 시기상조라고 보고 있고요.

    어쨌든 하시고자 하시는 말씀을 알겠지만 지금 상황에 적절하다고 보이진 않습니다

  • 페코옹
    1k
    2020-12-08 15:40:00
    https://codesandbox.io/s/github/reduxjs/redux/tree/master/examples/counter?from-embed

    리덕스 홈페이지에 나와있는 카운터 공식예제에요~

    액션을 별도로 빼서 글로벌하게 사용하는 경우도 있고
    리덕스 툴킷에서처럼 아예 액션을 만들어주는 경우도 있고
    전 리덕스랑 context랑 결합해서 사용하고 있고

    리덕스를 사용하는 다양한 사용법이 있다는 이야기에요~

    굉장히 심플한 카운터예제 만드는데 아무것도 아닌 리덕스 구조차이로 코드가 개판이라고 할건 아니라는 거죠


  • ISA
    5k
    2020-12-08 16:05:09 작성 2020-12-08 16:10:03 수정됨

    페코옹 //

    그냥 만들거면 하드코딩 하든 말든 누가 뭐라 하겠습니까?

    그냥 자기 마음대로 만들면되는거죠. 해당 예제는 가장 기초적인 리덕스 사용응 보여주기 위해서 고의적으로 코드를 단순화 시킨 사례인데 그걸 가지고 스탠다드 패턴이나 기타등등 (하다 못해 그 예제 아래 투두 리스트만 해도 action을 나누는데) 다 무시하고 리덕스 사용법은 다양하니까 아무렇게나 써도 된다는 식으로 주장하시면 곤란해요. 코드 막짜도 된다는 소리랑 비슷합니다.

    애초에 잘 아는 사람이야 그렇게 써도 크게 문제 될게 없지만 글쓴이가 그런 경우가 아니지 않습니까? 툴킷조차 상태 구조는 기초적인거 지켜가면서 만드는데 왜 저걸 옹호 하시는지 모르겠네요. 그냥 저랑 말다툼을 하고 싶어 하시는 정도로 보입니다.

    저도 ts에 react redux쓰면서 리액트은 hook +fp 리덕스는 class 형태로 해서 쓰지만 그건 개인적인 선호상 리액트 훅을 통한 결합보다 기존 결합이 좀 더 직관적이라는 이유로 쓰는것이고 스탠다드에서 크게 벗어 나지는 않습니다. 정형화 된 구조로 딱 붙잡기에는 개발 환경에서 오는 설계의 다양성이나 발전 가능성에서 손해를 보니 그렇게 정하진 않지만

    기초적인 부분 조차 지키지 않으면 의도치 않은 오류가 발생하고 유지보수가 힘들어진다는걸 잘 아시는분이...

  • 페코옹
    1k
    2020-12-08 16:27:52

    네 ISA 님이 말씀하시는 부분 충분히 이해합니다.

    처음 배울때 기초를 확실히 잡고 가는게 중요한거 동감합니다.

    그런데 지금 글쓴이 질문하시는 요지나 예제의 성격상 굳이 스탠다드에 맞지 않는다고 공격적인 언행을 해야하냐 이거죠~

    학습 방법론적인 측면에서도 지금 중점적으로 배우고 있는 부분이외 다른 부분들은 어느정도 추상화하고 단순화하는게 이해를 더욱 쉽게 하는 부분 이기도 하구요 (리덕스 공식 예제 처럼요~)


  • 페코옹
    1k
    2020-12-08 16:31:41

    리덕스를 더 공부하시거나 혹은 프로젝트 진행하시다 보면 관리하는 스토어도 늘어나고 자연스럽게 확장성있는 패턴이나 구조에 대한 공부하면서 실력이 느시지 않겠습니까? ㅎㅎ

  • ISA
    5k
    2020-12-08 17:09:12 작성 2020-12-08 17:11:26 수정됨

    페코옹 //

    정확하진 않지만 현재 글쓴이는 카운터가 아닌 todo를 하고 있습니다. Todo에서는 페코님이 말하신거 처럼 단순화해서 가르치지 않습니다. 그 단계는 카운터에서 끝났습니다.

    그러니 지적해야죠.

    애초에 저도 개판으로 리덕스 코드 짜본 적 있는데 그 중 대표적인 걸 말하면 리덕스 사가 없이 비동기를 처리해보고 싶어서 실험적으로 짠 적이랑 리듀서를 getter setter처럼 써서 순수함수가 아니게 짠 적 있습니다. 면접에서 해당 부분을 지적 받았을때 솔직히 "내가 그때 해당 이유로 개판으로 짰다, 내가 봐도 개판이다." 라고 솔직히 말했습니다.

    개판이라는게 공격적으로 들리시면 스파게티 코드라는 말로 할까요? 뜻은 같습니다.

    글고 애초에 스토어는 늘어나면 안됩니다. 특별한 이유가 없는한 원칙적으로 상태관리는 단일 스토어 원칙을 고수하니까요. 실제로 해당 코드는 컴바인 리듀서를 하는 부분이 없기에 단일 스토어 아니게 될 확률이 높긴하네요.

    어느 정도 의견의 교집합이 생긴 것 같으니 저는 이쯤에서 해당 주제로의 논쟁은 그만하겠습니다.

    페코옹님도 건승하시길 바랍니다.

    어쨌든 글쓴이는 js 기본기랑 리액트 리덕스 기본기를 조금 더 공부해야할거같네요.

  • pistis
    290
    2020-12-10 10:01:38

    가벼운 마음으로 게시글을 보러 들어왔다가 많은 댓글들을 읽다보니 다 읽게 되었네요.


    말이란게 참 힘든 거 같습니다.

    ISA님과 페코옹님 말씀 중 잘못된 부분들은 없는 거 같아요.


    다만, ISA님 첫 댓글에서 "구조가 개판인거 같네요." 라는 이 문장이 달랐다면? 하는 아쉬운 마음이 조금 있네요.

    보통 실무에서는 혼자서 개발하기보다는 대부분은 팀으로 개발하며 

    github pull request 등을 통해서 온라인으로 활발히 코드리뷰도 하고 때로는 오프라인으로도 리뷰 및 페어 프로그래밍을 하면서 일을 하게 되지요.


    그런 의미에서 ISA님의 첫 댓글의 첫 문장이 의사를 전달하기에 좀 더 부드러운 표현이었으면 어땠을까 하는 아쉬움이 있는 건 사실입니다.

    코드리뷰할때 "구조가 개판인거 같네요" 라고 리뷰를 하지는 않으니까요.


    사실 그 문장만 제거하고 댓글을 본다면 너무 명확하게 질문에 대한 답을 주셔서 뭐 더할나위 없지만요. ^^;



  • ISA
    5k
    2020-12-10 10:31:27

    pistis //

    코드리뷰까지 할 생각도 없었습니다. 코드가 개판이라는 평가를 민감하게 받아들이는 사람들이 많은거 같긴하네요.

    솔직히 나머지는 페코옹님 한테 대답한 것이지 글쓴이한테 대답한 것도 아니긴하네요.

    애초에 전 흔히 말하는 재능충이라는 부류고 딱히 스터디나 과외 같은거 안받고 그냥 독학한 편이고 처음부터 개발에서 어려운 부분이 잘 없는편에 어지간한 기술들 러닝커브 하루도 되지 않아서 그런지 기본기가 너무 부족한 글들에 공감이 잘가지 않습니다. 처음 학습할때 부터 저런 질문들이 이해 안간 적도 없고 기본적으로 그냥 혼자 나아갈 방향을 자연히 느껴서 혼자 찾아서 발전하는 스타일이니까요.(솔직한 감정으로는 고의적이고 게으른게 아닌가라고 느낍니다.)

    그래서 그런지 평소 가스라이팅도 많이 당하는 (판단력이 흐려지진 않지만) 편인데 본의 아니게 비슷한 느낌으로 한거 같긴하네요.

    말을 부드럽게 해야한다는 조언은 참고하겠습니다.

    -1
  • 로그인을 하시면 답변을 등록할 수 있습니다.