그런데 문제는 시니어급들 포함 나까지 리액트로 큰 프로젝트를 만들어본적이없다...
좋은 팁이나 뭔가 주의 해야되는 상황 없냐?
나는 대충 컴포넌트가 언제 랜더링 되는지 하고
리렌더링을 방지하는 여러 기본 훅들 사용하는정도만 암
지금은 ASP.NET에다가 JQuery JS스크립트 꼽아서
UI로직 하고 뒤에 백앤드 DB가 열일하는 중인데
리덕스는 안쓸생각이시고 context api를 주로 사용할 예정이다
그리고 코어 컴포넌트는MUI에서 가져와서 어느정도 스타일링후 패키지로 만들어서 따로 npm 으로 해서 퍼블리쉬 그리고 다른 미래 프로젝트들하고 쉐어하게할 생각인것 같다
그런데 타입스크립트의 상속도 함수가 어떤 타입들을 가지고 있는지까지는 강제못하겟지?
좋은 팁이나 뭔가 주의 해야되는 상황 없냐?
나는 대충 컴포넌트가 언제 랜더링 되는지 하고
리렌더링을 방지하는 여러 기본 훅들 사용하는정도만 암
지금은 ASP.NET에다가 JQuery JS스크립트 꼽아서
UI로직 하고 뒤에 백앤드 DB가 열일하는 중인데
리덕스는 안쓸생각이시고 context api를 주로 사용할 예정이다
그리고 코어 컴포넌트는MUI에서 가져와서 어느정도 스타일링후 패키지로 만들어서 따로 npm 으로 해서 퍼블리쉬 그리고 다른 미래 프로젝트들하고 쉐어하게할 생각인것 같다
그런데 타입스크립트의 상속도 함수가 어떤 타입들을 가지고 있는지까지는 강제못하겟지?
그냥 웹폼으로 드래그 앤 드랍 하셈
context api 리렌더링 때문에 별로... 리덕스처럼 useSelector 사용하는 곳만 리렌더링 되는게 아니라 감싸고 있는 자식들 전체가 리렌더링돼서 공유하는 값이 자주 바뀌면 자주 리렌더링 됨.. 큰 프로젝트면 리덕스든 뭐든 가야돼
감싸고있는 자식들 전체가 아니라 useContext의 상태에 의존하고있는 컴포넌트 만 리렌더링 되는줄 알았는데 모르겟다
그게 useContext 의 상태에 의존하는 컴포넌트를 리액트가 감지를 못함. 애초에 변경한다는거 생각해보면 컨텍스트에서 state 만들어서 setState 까지 같이 내려주는 방식임. 제일 위에서 state가 바뀌면? 반면 리덕스는 리액트 외부(리덕스코어)에서 상태 관리하고 useSelector 내부에 state 이용해서 딱 selector 쓰는 컴포넌트만 리렌더링 되는거임. 액션 디스패치되면 selector 내부 state 변경되도록 subscribe 해두는 식으로.
https://ridicorp.com/story/how-to-use-redux-in-ridi/
읽어보시면 될듯
https://github.com/dai-shi/use-context-selector
요런거
있기도 한데..
context의 또 다른 문제는 전역 상태 변경만 하는게 아니라 전역 상태 변경 '관리'가 필요한 거니까..
context에서 상태 변경하는건 기본적으로는 데이터를 일관적으로 변경한다는거에 대한 개념이 아닌듯. 걍 공용 자원에 접근해서 변경하는거..
만약 복잡도가 크지 않아서 context쓰더라도 useReducer를 통한 상태 배포 필수. 다만 리랜더링 오질 수 있음.
리액트로 하는김에 next로 하는거 추천
이미 백앤드는 asp.net core 6로 만드는중임
vuejs 하실?
해당 댓글은 삭제되었습니다.
솔직히 모르겟음 그냥 고객이 좋아하는 듯 그리고 현재의 웹사이트UI가 조금 늙은 느낌도 크기도하고 (사실 css 만바꾸는 옵션도 있엇음)
또 js Jquery의 설랙터를 써서 코드를 짜는게 살짝 js 코드들의 로직이 너무 싸이다 보니 부패하기 시작한듯 aspx, ascx페이지당 2000줄짜리 js파일이 뒤엉켜있음 그리고 점점 구조를 읽는게 귀찮아짐 사실 큰이유는 고객의 원하는거지 큰문제는 없었음
채용 문제도 있지 않을까 싶네 ㅋㅋ
ㄴ 고객이 원한다는데 뭔소리야 글쓴이가 개발하고 유지보수하는데 문제없었다잖아
주의할것. 1. ssr, csr, app-router 등에 따라 기술 스택이나 처리 방식이 달라질 수 있음. 2. 리액트는 항상 상태 기준으로 그려짐. jquery로 하던 방식과는 완전 패러다임이 반대니 이런 부분 참고. 이런 코드의 장점은 컴포넌트 설계하고 짜기 쉬움. 3. css는 잘 모르겠으면 스타일드컴포넌트나 emotion같은 솔루션보다는 css 솔루션이 나을 수 있음. 4. 라우터 컨트롤 꽤 어려울 수 있음. 사용하려는 프레임워크나 라우터 라이브러리는 미리미리 참고 해두는게 나음. 5. rest-api요청은 react-query, rtk query, swr을 쓰는게 남. 이걸 그냥 직접 처리하려고 하면 꽤나 코드량도 많아지고 복잡해짐. 6. 서비스의 복잡도에 따라서 적합한 상태관리 고르는게 좋음.