react

리액트를 배우다 보면 자연스럽게 훅(Hook)에 대해 접하게 된다. useState, useEffect 같은 기본적인 훅을 사용하며 컴포넌트의 상태를 관리하고, 생명주기를 다루는 방법을 익히게 된다. 동시에 리액트에서는 훅을 사용할 때 반드시 지켜야 할 몇 가지 규칙이 있으며, 이를 어기면 예기치 않은 오류가 발생할 수 있다는 이야기를 듣게 된다. 리액트 공식 문서에서도 이를 강조하고 있다. 훅은 최상위에서만 호출해야 하며 조건문이나 반복문 안에서는 사용할 수 없다. 반드시 리액트 함수 내에서만 호출해야 하며 클래스 컴포넌트에서는 호출할 수 없다.도전적인 개발자라면 주어진 규칙에 무조건적으로 순응하지 않는다. 대신, 그 규칙이 반드시 지켜야 할 절대적인 원칙인지, 아니면 단순한 관례인지 직접 검증해본다...

이전에 [ 유틸리티 컴포넌트 : Show & Map ]에서 잠깐 언급했었던 것처럼, 나는 꽤 오래 전부터 여러 조건을 일괄적으로 처리하는 Switch와 Match 컴포넌트를 만들고 싶어했다. 대강 어떻게 만들지에 대한 아이디어는 여럿 있었지만, 실제로 구현하려니 문제가 산더미였다.처음에는 타입스크립트를 사용하려 했다. 그러나 수많은 시행 착오 끝에 나는 [ 타입스크립트에서의 컴포넌트 추론 ]의 결론에 도달할 수 있었고, 타입스크립트를 사용하여 Switch 컴포넌트를 정의하려는 나의 아이디어는 물거품이 되어버렸다. 머리를 열심히 굴려보았지만 방법이 없었다. 나는 런타임에서 에러를 던지는 것으로 스스로와 타협했다. 그렇게 만들어진 Switch 컴포넌트는 아래와 같다. 런타임에서 ReactElement는 객체..

Jest는 Facebook에서 개발한 JavaScript 테스트 프레임워크로써 간단하고 직관적인 API와 강력한 기능을 제공한다. Nest.js는 테스트 도구로서 Jest를 기본 제공하고 있고, React나 Next.js에서는 testing-library를 사용해 Jest 테스트를 수행할 수 있다.Jest의 가장 큰 장점 중 하나는 설정이 거의 필요 없다는 점이다. 다른 테스트 프레임워크들은 종종 복잡한 설정이나 외부 라이브러리의 설치가 요구되지만, Jest는 기본적으로 거의 모든 기능을 내장하고 있어 별다른 준비 없이 바로 사용할 수 있다. 또한, 자동화된 테스트 실행과 빠른 피드백을 제공하여 개발 과정에서 코드 변경 시마다 수동으로 테스트를 실행하는 불편함을 줄여준다.  기본 문법Jest는 test ..

합성 컴포넌트 패턴이란 무엇인가합성 컴포넌트 패턴(Composite Component Pattern)은 컴포넌트를 보다 유연하게 구성하고 재사용할 수 있도록 여러 하위 컴포넌트를 조합하여 만든 컴포넌트이다. 세간의 인식은 조금 더 복잡한 무언가를 예상하는 듯하지만, 실제로는 리액트를 사용하는 사람이라면 누구나 children을 통해 합성 컴포넌트 패턴을 사용하고 있다.function Dialog({ children }) { return {children};}function App() { return ( 이것은 합성 컴포넌트입니다. );} 만약 특정한 형태의 컴포넌트만을 사용하고 싶다면 children 대신 다른 props 이름을 사용하여 아래와 같이 구현할 수도 있다. pro..

상황내가 혼자 개발하고 있는 onef에 댓글 기능을 추가하기로 했다. 우선은 댓글 작성 로직과 작성 컴포넌트를 구현하였다. 이후에 댓글 수정 기능이 필요하다는 걸 깨닫고 보니 댓글 작성 로직에서 post만 put 메소드로 바꿔주면 된다는 사실을 알게되었다. 이를 위해 댓글 작성 컴포넌트에서 해당 로직을 추출하고, 필요한 로직은 Context를 사용해 외부에서 주입하는 방식으로 변경하였다.// CommentMutation.tsexport class CommentMutation extends MutationFn { constructor() { super(); } postComment() { return ({ parentId, value, depth }: { parentId: string; v..

내가 쓸 목적으로 만든 독후감 기록 및 공유 서비스가 하나 있다. 이름은 onef인데, 홍보에 그렇게 열중하지 않았더니 쓰는 사람이 나랑 내 후배들 정도 뿐이다. 하지만 상관 없다. 구현해보고 싶은 기능을 부담 없이 해볼 수 있는 테스트베드로서의 기능은 충분히 만족하고 있으니까. 이 서비스의 프론트와 백엔드는 모두 내가 구현했는데, 각각 NextJS와 NestJS를 사용했다. 데이터베이스는 postgreSQL을 썼는데, SQL을 모르는 관계로 ORM인 Prisma를 사용했다. 재귀적 관계 테이블댓글 기능을 추가하는 건 간단하다. 그런데 대댓글은 어떻게 구현해야 할까. 이에 대해 찾아보다가 RDB에는 재귀적 관계라는 게 있다는 걸 알게되었다. 풀어서 쓰면 자기 자신을 참조하는 모델 연결이라고 해야겠다. P..

예전에 멘토님께서 이런 이야기를 해주신 적이 있다. "각 라이브러리가 어떻게 라우팅을 구현하고 있는지를 외우고 있는 건 하나도 중요하지 않다. 정말 중요한 건 이들 라이브러리가 해결하고자 하는 어떤 공통된 문제가 존재한다는 것이며, 따라서 라우팅을 지원하는 라이브러리가 해결하고자 하는 문제가 무엇인지를 알아야 한다. 이걸 알고 나면 각각의 라이브러리가 이 문제를 어떻게 해결하는 지는 그냥 공식 문서 찾아보면 된다." 이 말은 비단 라우팅 뿐 아니라 '라이브러리' 전체에 동일하게 적용할 수 있는 격언이라 생각한다. NextJS는 페이지 라우터와 앱 라우터를 지원하고, React 수준에서는 오래전부터 React-Router를 사용해 CSR 라우팅을 처리해왔다. 이들은 모두 라우팅 문제 해결이라는 공통된 목적..

앞서 작성한 input 연대기 초반에 잠깐 언급했었는데, 내가 프론트엔드 공부를 처음 시작했을때부터 지금까지 꾸준히 고민하고 있는 문제 중 하나가 'Button과 Link가 같은 스타일을 가질 때 어떻게 처리할 것인가'이다. 이 두 개의 컴포넌트는 받는 props의 타입도 조금 다르고, 클릭했을 때의 동작도 다른 편이지만, 결국은 '클릭할 수 있는 영역'이기 때문에 UI 적으로 비슷하거나 동일한 디자인을 가져가는 경우가 종종 있다. 처음에는 하나의 스타일시트를 만들고, Button과 Link 컴포넌트에 className으로 동일한 css를 넘겨줄 생각이었다. 그러나 이 방법은 곧 한계를 드러냈다. 내가 간과한 사실 중 하나는 '스타일은 결국 여러 옵션의 내용(size, color etc)을 중첩하여 사용..

내가 프론트엔드 공부를 처음 시작했을때부터 지금까지 꾸준히 고민하고 있는 문제가 둘 있다. 하나는 다음 포스트에서 풀어볼 'Button과 Link가 같은 스타일을 가질 때 어떻게 처리할 것인가'이고, 다른 하나는 input의 type을 text와 password로 바꿔주는 기능을 어떻게 처리할 것인지에 대한 것이다. 회원가입/로그인 폼을 생각해보면 거기에는 늘 비밀번호 입력을 감출 수 있는 눈동자 버튼이 있다. 이 눈동자 버튼을 누르면 input의 type이 password에서 text로 바뀌고, 다시 누르면 그 반대로 바뀌게 된다. 리액트를 배우고 한 시간 정도면 아마 누구라도 구현할 수 있을 지 모른다.그런데 이 눈동자가 토글된 상태는 어느 컴포넌트에 위치시키고, 눈동자 버튼은 어디에 배치해야 하며,..

나는 다른 라이브러리나 프레임워크의 공식 문서를 보면서 좋은 코드에 대한 아이디어를 얻는 편이다. 그리고 어제는 SolidJS를 살펴보다가 굉장히 재미있는 아이디어 하나를 캐치할 수 있었다.기존에 나는 특정 조건에 따라 컴포넌트를 다르게 처리함에 있어 아래와 같은 방식으로 코드를 작성했다. 아주 일반적인 방법이지만 컴포넌트와 JS 로직이 뒤섞여서 전체적인 코드의 통일감을 해친다는 인상을 받았다.export default function Comp() { const [count, setCount] = useState(0) const list = [1, 2, 3, 4, 5] return ( {count > 5 ? "숫자가 5보다 커요" : "숫자가 5와 같거나 작아요"} ..

리액트를 처음 배우던 시절 나는 비동기 데이터를 다루는 방식의 하나로 useAsync라는 이름의 커스텀 훅을 접하게 되었다. 이는 컴포넌트 내부에서 비동기 작업을 안전하게 처리하기 위한 수단이었는데, 그 코드를 기억나는대로 작성해보자면 아래와 같았다.export const useAsync = (fn) => { const [state, setState] = useState({ data: null, loading: true, error: null }); useEffect(() => { const fetchData = async () => { try { setState((prev) => ({ ...prev, loading: true })); ..

생각보다 많은 사람들이 context API를 유사 전역상태관리 도구로 여기고 있고, 사실 나 역시도 처음에는 그렇게 알고 있었다. 그러나 잠깐 생각해보면 context API(이하 컨텍스트)의 존재 이유가 전역 상태 관리와는 전혀 상관이 없다는 걸 금방 알 수 있다. 아마 리액트 개발자라면 누구라도 이렇게 대답할 것이다. "컨텍스트를 사용하면 prop drilling을 방지할 수 있다."그렇다면 어째서 대부분의 사람들 ─ 혹은 리액트 1~3년차들 ─ 은 무의식 중에 컨텍스트를 유사 전역상태관리 도구라 여기고 있는 것일까? 여기에는 크게 두 가지 이유가 있다고 본다. 하나는 컨텍스트를 활용하는 예시가 대체로 state와 setState에 치중되어있기 때문이다. 심지어는 이를 새로운 커스텀 훅으로 감싸 진..