프론트엔드/유용한 도구들

랭체인(LangChain)은 AI 모델과 다양한 데이터 소스, 도구들을 연결해 복잡한 애플리케이션을 쉽게 구축할 수 있도록 돕는 프레임워크이다. 원래 파이썬 기반으로 많이 알려져 있지만, 최근에는 타입스크립트 지원도 활발해져 프론트엔드 개발자나 Node.js 환경에서도 효율적으로 활용할 수 있다. 타입스크립트 랭체인은 강력한 타입 시스템과 친숙한 문법 덕분에 안정적이고 생산성 높은 AI 통합 개발을 가능하게 한다. 모델 생성ChatOpenAI 인스턴스를 생성하는 것은 LangChain에서 OpenAI 기반 챗 모델을 사용하기 위한 첫 번째 단계이다. 이때 modelName, temperature, openAIApiKey 등의 옵션을 설정하여 사용할 모델의 종류, 응답의 창의성 정도, 인증에 사용할 AP..

이번 주, sicilian과 caro-kann 모두 3.1 버전을 공개했다. 하나는 폼 관리 도구이고 다른 하나는 전역 상태 관리 도구라는 차이가 있지만, 이번 업데이트에서는 공통적으로 '런타임 타입 체크' 기능이 추가되었다. sicilian의 경우, 이전에도 내장된 validator를 통해 런타임 타입 검증이 가능했으나, zod, yup, superstruct와 같은 외부 스키마 라이브러리를 활용해 사용자 정의 검증 로직을 통합하는 방법은 존재하지 않았다. 그러나 3.1 버전부터는 이러한 스키마 라이브러리들과의 연동이 간편해졌고, 폼 데이터의 유효성 검사는 물론 구조와 타입까지도 런타임에서 명확하게 검증할 수 있게 되었다.sicilian에 외부 스키마 라이브러리를 통합하는 것은 오래전부터 품어온 염원이..

현대의 개발 환경에서 도커(Docker)는 빠르게 개발하고 배포할 수 있는 핵심 도구로 자리 잡았다. 도커를 사용하면 애플리케이션 실행 환경을 컨테이너라는 독립된 단위로 포장할 수 있으며, 이를 통해 운영체제에 관계없이 동일한 환경에서 애플리케이션을 실행할 수 있다. 이러한 장점 덕분에 개발, 테스트, 배포 전반에 걸쳐 일관성을 유지할 수 있으며, 특히 팀 협업 시 환경 차이로 인한 문제를 크게 줄일 수 있다. 이미지 관리도커에서 이미지(Image)란 컨테이너 실행에 필요한 파일 시스템과 설정 정보를 포함한 읽기 전용 템플릿이다. 애플리케이션 코드, 라이브러리, 의존성, 환경 변수, 실행 명령어 등이 포함되어 있으며, 컨테이너는 이 이미지를 기반으로 실행된다. 쉽게 말해, 이미지는 컨테이너의 '설계도'..

이 문서는 sicilian@3.0.8을 기반으로 작성되었습니다.sicilian@3.0.0의 기본적인 문법은 [ 여기 ]에서 확인하실 수 있습니다. 전역 상태 기반 form 관리 라이브러리 sicilian은 프론트엔드에서 작성하게 되는 form의 형태를 크게 세 가지로 분류합니다. static form, dynamic form, 그리고 dynamic input이 그것입니다. 각각의 form이 어떤 형태를 갖는지 설명하기 전에, 우선은 프론트엔드에서 가장 일반적인 형태의 form인 static form을 sicilian으로 구현해보겠습니다. static form정적 서식은 form이 어떤 특정 조건에 의해 생성되거나 하지 않으며, 내부의 input 종류도 고정적인 경우를 말합니다. 정적 서식의 대표적인 예시..

요즘 나는 아래와 같이 다섯 단계에 걸쳐 컴포넌트에 데이터를 넣어주고 있다. 각각의 단계는 한 줄로 정의되는 최소한의 책임을 구현하며, 이번 포스트를 통해 추상 클래스 Fetcher 내에서 어떻게 options를 정의하고 있는지와 그것을 각 클래스 Repository에서 어떻게 사용하는지에 이야기해보고자 한다.axios.instance of graphql.client // 백엔드 호출 방법=> abstract class Fetcher // 백엔드 호출 로직 및 options 함수 정의=> class Repository extends Fetcher // 도메인 별 queryFactory 및 repository 패턴 구현=> useAdaptor // 백엔드 인터페이스와 프론트 인터페이스를 매개=> react..

[ Github / NPM ] Utilinent는 SolidJS의 간결하고 직관적인 Control Flow API를 React에 도입하고 발전시켜, 개발자들이 더욱 생산적이고 효율적으로 작업할 수 있도록 돕는 것을 목표로 합니다. React에서 자주 사용되는 패턴과 조건부 렌더링 로직을 컴포넌트로 감싸는 방식으로 재사용성을 높이며, 이를 통해 대규모 프로젝트에서도 코드 스타일을 일관되게 유지할 수 있습니다. 또한, 가독성이 뛰어난 코드를 작성하고 복잡한 로직을 단순화하여 유지보수를 더욱 편리하게 만듭니다. install 및 importnpm i utilinentimport { Show, For, Switch, Match, Mount } from "utilinent" ShowReact에서 조건부 랜더링을 ..

이 포스트의 내용 대부분은 카토 다이시의 [리액트 훅을 활용한 마이크로 상태 관리]에서도 찾아볼 수 있습니다. 전역 상태 관리 원리를 더욱 깊게 이해하고 싶으시다면 해당 서적을 여러번 읽어보시는 것을 권해드립니다. [ Caro-Kann으로 알아보는 전역 상태 기본 원리 ]에서 이어지는 내용입니다.  useSyncExternalStore우리는 이전 포스트에서 useState를 사용하여 발행-구독 패턴을 처리하였다. 하지만 널리 사용되는 전역 상태 관리 라이브러리들은 useState 대신 useSyncExternalStore 훅을 사용하여 발행-구독 패턴을 처리한다. 이 훅은 리액트 18부터 제공되며, 외부 스토어의 업데이트가 컴포넌트의 리랜더링과 정확하게 동기화되도록 보장해준다. useSyncExterna..

이 포스트의 내용 대부분은 카토 다이시의 [리액트 훅을 활용한 마이크로 상태 관리]에서도 찾아볼 수 있습니다. 전역 상태 관리 원리를 더욱 깊게 이해하고 싶으시다면 해당 서적을 여러번 읽어보시는 것을 권해드립니다.  전역 상태란 무엇인가대부분의 프론트엔드 개발자라면 원하든 원하지 않든 전역 상태를 사용해본 경험이 있을 것이다. 이를 구현하기 위해 일반적으로 Zustand와 Jotai, Redux Toolkit 같은 라이브러리를 사용하게 된다(제발 useContext를 이런 용도로 쓰지 말아주세요). 그런데 이런 라이브러리들은 어떻게 전역 상태를 구현하고 있는 걸까? 또, 애시당초 전역 상태란 무엇일까?근본적인 의문으로부터 이야기를 시작해보자. 리액트에서 '상태(State)'란 무엇일까. 누군가 이에 대해..

Apollo Client는 클라이언트 환경에서 GraphQL을 사용하여 서버와 데이터를 효율적으로 주고받을 수 있도록 돕는 강력한 라이브러리이다. 주로 React를 비롯한 다양한 프레임워크와 잘 통합되며, 클라이언트에서 발생하는 요청을 효율적으로 관리하고, 데이터 상태를 예측 가능하게 유지하는 데 도움을 준다.Apollo Client가 제공하는 useQuery와 useMutation은 React Query의 그것과 유사하게 동작한다. 중복된 요청을 캐싱하여 네트워크 사용을 최소화하고, 데이터의 일관성을 유지하는 데 도움을 준다. 서버 상태를 관리하기 위한 이 두 도구는 각자 가진 장점이 달라서, 일반적인 REST API 요청의 경우에는 React Query를 쓰고, GraphQL 요청의 경우에는 Apol..

개인적으로는 이것저것 커스텀 훅을 만들어서 라이브러리 없이 인풋을 처리해왔지만, 슬슬 한계가 오고 있지 않나 싶다. 마침 새로운 프로젝트에서는 인풋을 React-hook-form(줄여서 훅폼)으로 관리하자는 이야기가 나와서 ─ 새로운 기술을 배워야할 때 늘 그래왔던 것처럼 ─ 공식 문서를 좀 읽어보았다. 쓸만한 것들(useful 말고 will use)을 여기에 조금 남겨본다. useForm optional arguments useForm 훅은 여러 옵션을 설정할 수 있는 하나의 객체를 받아서, 인풋에 달아줄 수 있는 다양한 함수와 객체와 값들을 리턴한다. mode onChange | onBlur | onSubmit | onTouched | all mode 속성은 input validation을 어느 시점..

최근에는 page router에서 벗어나 app router의 기능을 써보려는 시도를 조금씩 해보고 있다. Next.js 13.4부터 server action 이라는 기술이 도입되었지만, 아직 react query를 완전히 대체할 수는 없는 것 같다. 따라서 이 글에서는 getServerSideProps가 없는 곳에서 이정도의 prefetch를? 할 수 있는 방법에 대해 알아보려 한다. 환경 설정 page router 환경에서는 _app.tsx에 QueryClientProvider를 만들어 감싸주었다. 그러나 app router에서는 Provider.tsx라는 컴포넌트를 별도에 만들고 이를 Layout.tsx의 return 안에 있는 children을 감싸는 형태로 사용하게 된다. 오직 클라이언트 컴포넌..

이전 프로젝트에서는 Jotai를 사용했는데, 이번 프로젝트는 나 빼고 다 Zustand를 사용하는 까닭에 내가 팀원들에게 맞춰야지 하고 있다. 공식 문서 읽으면서 필요하다 싶은 부분들을 정리해보았다. Provider의 부재 Jotai는 Provider와 Store를 통해 값을 제한할 수 있는데, Zustand에서는 그런 기능은 없는 듯하다. 이게 장점인지 단점인지는 모르겠다. 일반적으로 상태관리 도구는 전역 상태관리를 위해 사용하는 경우가 많으므로 크게 문제가 되지는 않을 것 같다. Store useReducer 훅과는 비슷한 것 같으면서도 다르다. 여기서는 store를 생성할 때 초기값과 액션들을 미리 지정하는 듯하다. 일전에 누군가 내게 'Zustand의 구조가 객체지향적이라 Jotai보다 Zusta..