수많은 사용자가 사용하는 웹 사이트가 있다고 가정해보자. 이러한 웹 사이트는 수많은 유저들에 의해 다양한 요청이 서버에 도착할 것이고, 서버는 이에 맞는 응답을 네트워크를 통해 전달할 것이다. 네트워크의 제한된 대역폭에 비해 출력량이 많아진다면 당연하게도 네트워크 지연이 발생하게 된다. 즉 대역폭 병목현상이 발생하게 된다. 물론 이벤트성 페이지에서 12시 정각에 상품 구매창이 열린다던지, 대학 수강신청과 같이 한 순간에 대량의 유저가 몰리는 경우와 같이 어쩔수 없이 지연이 발생하게 되는 상황은 지연이 발생할 수 밖에 없는 과정을 인정하고 이에 대한 해결책을 강구해야할 것이다. (이벤트 페이지의 구매창 클릭 버튼을 맨 밑에 위치시키는 등으로 급격하게 너무 쉽게 사용자가 몰리는 상황을 예방하는 방법도 있겠다..
지난 포스팅때는 React-Hook-Form 을 활용하여 Add 페이지와 Detail 페이지 내에서 활용될 입력 컴포넌트 ItemForm 을 구현하였다. 구현하는 과정에서 의류 카테고리에 따라 실측 입력폼을 렌더해야 하는 문제에 대한 고민과 이를 해결하고자 어떤식으로 코드를 구상하였는지도 다루어 보았다. 다만, 아직 ItemForm 에서 해결해야 할 문제들이 남아있는데, 크게 3가지 정도라 할 수 있겠다. 의류에 대한 정보를 수정하고 싶을 때, 수정 버튼을 누르면 ItemForm 내 기존 의류의 정보가 기입되어있어야 하며, 수정하여 변경할 수 있어야 한다 중요한 부분이 이미지를 업로드 하는 과정인데, 우선 이미지 업로드 버튼 뿐 아니라 웹사이트 내에서는 이미지를 드래그에서 업로드 하는 방식도 추가하고 싶..
입력 폼은 웹페이지를 구성할 때 빠지지 않고 포함되며, 그렇기에 html 내 input 의 type 들 역시 기본적인 입력부터 시작하여 number, tel, select, color, file 등등 다양하게 존재한다. 상황마다 달라지겠지만 기본적으로는 이메일과 비밀번호를 입력하는 로그인부터, 유저의 다양한 정보들을 한번에 전송해야 하는 입력폼을 생성해야할 때도 존재한다. 진행중인 closet 프로젝트에도 입력폼은 반드시 포함되었어야 했는데, 당연하게도 로그인 및 회원가입때의 입력폼과, 프로젝트의 핵심이라 할 수 있는 의류들의 정보들을 입력하게 될 add 페이지와 입력했던 의류정보를 수정하게 될 detail 페이지에서 사용될 입력폼이 필요했고, 그렇기에 좀 더 입력폼을 구현하는데 수월한 방법이 없을 까 ..
useEffect 는 컴포넌트의 라이프사이클을 함수형 컴포넌트 내에서 조절할 수 있도록 제공되는 react hook 중 하나이며, 실제 react 로 컴포넌트를 구현하는 과정에서 아주 유용하고 자주 사용되는 hook 이라고 할 수 있다. 매 컴포넌트가 랜더링 될 때마다 필요한 sideEffect 를 다룬다던지(서버와의 통신), state 나 props 의 변화로 인한 다른 요소의 업데이트가 필요한 경우, 실제 컴포넌트가 unmounting 될 때의 상황에서 useEffect 는 필수적으로 활용되곤 한다. 그치만 실제 작업을 해보다보면 알겠지만, 이것저것 기능을 추가하고 서로 연계를 하다보면 어느새 컴포넌트 내 useEffect 가 너무 과다하게 사용하고 있는것은 아닌가 의문이 들 때가 있다. 필요해서 사..
프로젝트를 진행하는 도중 form 제출 후 결과 페이지까지 구현하다 보니, 로그인이나 회원가입, 그리고 결과창이나 제출 시 버튼들이 제각각의 스타일을 지니고 있다는것을 인지하게 되었다. 비슷한 버튼들은 하나의 재사용 컴포넌트를 사용하는 것이 아니라 각각의 버튼을 각각의 컴포넌트에서 styled-component 로 동일한 스타일을 적용한 뒤 사용하고 있었다. 앞으로도 페이지나 다른 컴포넌트에서 버튼이 사용되게 될 때를 대비하여 버튼을 포함한 여러 element 들을 재사용 가능할 수 있도록 작성해야겠다고 생각이 들어서 따로 Button.tsx 를 생성하여 구현하기 시작했다. 이렇게 버튼을 생성하여 구현을 이어나가다 로그인 페이지에서 Sign In, Create Account 버튼과 아래 Google lo..
함수형 컴포넌트를 사용하다보면, useState 를 통한 상태변화를 동기적으로 처리하고 싶을 때가 있다. 예를 들면 우선 데이터를 받아와 상태를 변경하고, 이 변경된 상태를 props 로 다른 컴포넌트에 넘겨준다던지, 상태변화과정을 순차적으로 진행해서 연결시키고자 할때 등등이 있다. 그리고 이러한 의도로 코드를 작성하였다가, 제대로 작성하지 않은 경우를 맞이하게 되는데, useState 는 비동기적으로 작동하기 때문이다. 직관적으로 상태가 변화하고, 그 변화된 상태 데이터를 컴포넌트에 반영하는것이 이해과정에서 편하지만, useState 가 비동기적으로 작동되어야 하는 이유가 있다. 실제 리엑트 공식문서에서도 동기적 사용을 위한 메서드를 제공하긴 하지만, 거의 절대적으로 이를 사용하지 말라고 경고한다. 그..
리엑트를 사용하기만 했지... 프로젝트를 진행하면서 가장 많이 사용한 라이브러리(요새는 거진 프레임워크라 해도 될..)는 리엑트이다. 많이 사용하는 만큼 항상 사용하는 hook 과 패턴에 의존하는 편이 있어서 좀 더 리엑트에 대해 공부를 하고자, 다시 공식문서를 참고하며 여럿 유명하신 개발자분들의 의견들을 참고하고 있다. (감사합니다!) 그저 당연하게 사용해왔던 라이브러리의 동작 원리에 대해서 할 수 있는만큼 알아보는것이 좋겠다 생각이 들어서, 검색과 강의를 참조하여 아주 간략하게 리엑트를 구현해보았다. 구현하는 과정과 이를 통해 리엑트에서 제안하는 규칙에 대해서 다뤄보도록 하자. 이 포스팅은 김민태: React로 구현하는 아키텍쳐와 리스크 관리법을 참고하였습니다. 간략하게 기본 셋팅 자바스크립트로 구현..
Memoization : '이미 계산해 놓은 값을 메모리상에 저장해놓고 필요시 다시 재사용하는 기법' 이전에 (시간이 좀 흘렀지만..) 컴포넌트를 최적화 하는 과정에서, 전달하는 props 의 변화가 없을 경우 다시 렌더링 되는 것을 막아주는 기법으로 리엑트의 메모이제이션을 이용한다고 언급한적이 있고, 그에 대한 방법으로 React.memo 에 대해서 포스팅 하였다. 당시 예시를 통해서도 설명하였겠지만, props 로 함수 객체가 전달이 되었을 때는, 그 함수에 변화가 없더라도 매번 랜더링 시 새로운 객체로 생성되어 전달됨을 알 수 있었고, 그에 따라 React.memo 가 제대로 작동하지 않음을 알 수 있었다. 그 당시 같이 활용해 주었던 hooks 이 useCallback 이었는데, 이에 대해서 좀 ..
