이 연구는 부모 컴포넌트에서 자식 컴포넌트로 api를 주입한 뒤, 자식 컴포넌트에서 생성된 데이터를 기반으로 주입받은 api를 호출하도록 코드를 만드는 과정에서 아이디어를 받아 진행되었다. 원래는 단순히 클라이언트 사이드로 동작하는 부모 컴포넌트의 api를 자식 클라이언트 컴포넌트로 전달만 해주려 했는데, 어쩌다보니 서버 사이드 부모 컴포넌트의 서버 액션(server actions)을 클라이언트 컴포넌트로 전달할 수도 있음을 알게 되었다. 부모 컴포넌트(서버 사이드)// page.tsximport { ActionsContainer } from '@/containers/actions/actions-container'import { FunctionComponent } from 'react'interface ..
fetch를 할 때 매번 똑같은 코드를 치는 것이 비효율적이라 여겨져서 만든 fetcher 함수다.fetcher 함수를 이용하면 아무래도 fetch를 반복하여 소스 코드에 적을 필요가 없어지니 궁극적으로는 코드 가독성 향상 + 유지보수성 증대를 꾀할 수 있다. fetcher 함수는 객체를 파라미터로 가지며, 파라미터 객체는 { url, options, useToken } 을 프로퍼티로 가진다.url은 fetch에 사용될 주소값이 담겨있으며, options에는 request시 초기화가 필요한 fetch의 기본 옵션들이, useToken은 헤더의 Authorization에 토큰을 담을지 말지 여부를 결정하는 플래그가 담겨있다. type FetcherPropsType = { url: string optio..
컴포넌트의 호버 여부를 리액트 state와 연결하기 위해 만든 훅이다.'use client'import { RefObject, useEffect, useRef, useState } from 'react'export const useHover = (): [RefObject, boolean] => { const [isHover, setIsHover] = useState(false) const ref = useRef(null) const handleMouseOver = () => { setIsHover(true) } const handleMouseOut = () => { setIsHover(false) } useEffect(() => { const element = ref.curr..
데이터 테이블의 헤더에서 특정 컬럼에 대한 데이터를 서칭하는 기능을 만들던 도중 구현하게 된 디바운스 인풋 컴포넌트다. debounced-input.tsx// debounced-input.tsx'use client'import { useEffect, useState } from 'react'import { cn } from '@/libs'import { Input } from './input'interface DebouncedInputProps extends React.InputHTMLAttributes { className?: string value: string | number onDebounceHandler: (value: string | number) => void debounce?: nu..
gitlab CI/CD를 사용하여 runner를 EC2를 연결하는 과정에서 제목과 같은 에러 메시지가 발생했다. 사실 에러라기 보다는 러너가 정말 해당 프로젝트 인스턴스와 제대로 결합되었는지 확인하라는 메세지이다. ci/cd를 한번 구동해보면 에러 메세지가 해결되겠지만 그 과정은 시간이 꽤 걸릴 수 있다. 대신 runner가 설치된 클라우드에서 아래 명령어를 실행해주자. gitlab-runner -debug run 위 명령어를 입력하면 gitlab-runner의 config.toml에 저장된 모든 러너들을 한번 체킹하면서 프로젝트 인스턴스와 연결을 수행하게 된다. 러너와 인스턴스, EC2의 연결이 잘 된 상태라면 문제가 해결될 것이다.
소스코드 저장 시 eslint + prettier가 자동으로 동작하지 않을 때가 있다. 이는 VSCode의 settings.json에서 eslint와 prettier 관련 설정을 고쳐주면 해결된다. { // ... "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" }, "editor.formatOnSave": true // ... } 위 설정이 VSCode가 인지할 수 있는 eslint + prettier 설정이다. settings.json을 잘 컨트롤 하면 방금 실행한 설정 외에도 다채로운 설정을 할 수 있다. 전역설정 전역설정을 하려면 windows 운영체제 기준 C:\Users\유저명\AppData\Roaming\Code\User\s..
리포지토리 패턴 유지보수가 쉬운 코드 구조를 구현하는 방법은 제각각이지만 추구하려는 목표는 '코드의 응집도 증가와 결합도 감소'로 대부분 같다. 이를 위해서는 복잡한 로직을 가진 코드 뭉텅이를 여러 개의 레이어나 클래스로 분리하는 작업이 필연적일 수 밖에 없다. 아래 그림을 보자. A는 복잡한 로직이 하나의 레이어에 뭉쳐있는 것을 표현한 것이고 B는 복잡한 기능들을 레이어로 나눠놓은 것이다. A의 경우, 간단한 코드를 작성할 때 유리한 방식이다. 그러나 본질적으로 코드의 결합도가 높을 수밖에 없으므로 복잡한 기능을 구현해야할 때나 기능이 점차적으로 스케일업 되어야 하는 경우에는 작업량에 따라 수많은 에러와 유지보수 비용 증가가 발생할 것이다. B의 경우, 간단한 코드를 작성함에 있어서 사실상 시간적인 손..
사상누각 사상누각이라는 말이 있다. 모래위의 집이라는 말로써, 튼튼한 기초와 뼈대가 있어야 추후에 무너지지 않는다는 뜻이다. 이 말은 우리의 삶 어디에서나 통용될 수 있는 말 같다. 공부도 그렇고, 운동도 그렇다. 그리고 프로그래밍 또한 그렇다. 사실 프로그래밍만큼 사상누각이라는 말이 잘 어울리는 분야는 잘 없을 것 같다는 생각이 들 정도로 프로그래밍은 튼튼한 기초와 뼈대가 무엇보다 절실한 것 같이 보인다. 굉장히 작게 설계된 프로젝트가 나중에 살이 하나씩 붙더니 이내 거대해져서 관리가 어려워지는 경우가 발생했다고 가정해보자. 작은 사이즈의 프로젝트가 왜 어느순간에 엄청나게 비대해졌을까? 이는 아마도 프로그래밍이 논리적 작업이라는 특성 때문에 그런게 아닐까 싶다. 프로그래밍에는 물리적인 제약이 없어 개발..
설계?유지보수 잘 하려면 코드를 이쁘게 짜 놓아야 한다. 하지만 코드를 이쁘게 짜겠다는 선언만으로는 그렇게 할 수 없다. 건물을 지으려면 땅에 줄부터 그어놔야 하듯이 코드가 올라갈 기반도 뭔가 틀이 잘 잡혀야 코드를 깔끔하게 올릴 수 있는데 이번 시리즈에서는 설계를 위한 다양한 시도 끝에 내가 얼추 픽스하려고 하는 것들을 남겨보려고 한다. Nextjs의 레이아웃나는 레이아웃의 설계가 상당히 중요하다고 생각한다. 컴포넌트가 어디에 배치되고 어디에 표시될지 명확하게 설계가 되어야 앞으로 올릴 컴포넌트들을 블록 쌓듯이 착착착 올릴 수 있기 때문이다. 그런 점에서 Next.js에서 제공하는 레이아웃은 기능별, 페이지별 분리가 너무나도 편하게 설계가 되어있어 사용하기 편하다. 레이아웃에 대한 Next.js의 공식..
설계의 필요성 재직중인 회사에 자사 쇼핑몰도 생기고 커머셜 커뮤니티도 생길 것 같다. 나중에 유지보수에 허덕이지 않으려면 사용할 라이브러리 채택, 디렉토리 구조 등 간단한 설계를 미리 해놓는게 좋을 것 같다. 회사가 요구하는 기능 구현의 양은 선형적으로 증가하고 있다. 행복한 상황이지만, 아무래도 프론트엔드 개발자가 나 혼자뿐인 만큼 책임 소재도 그만큼 막중해지는듯 하다. 물론 백엔드 개발자분께서 간간히 도움을 주시고는 있다지만 도움을 받더라도 도와주시는 분께서 큰 고민 없이 코드만 치실 수 있도록 해드리는게 내 역할이지 않을까. 아무튼 여러 필요로 인해 프론트엔드 설계에 대한 정보들을 이것저것 모으고 있다. 일단 정보를 착실히 모은 후, 내것으로 만들어서 개발환경에 잘 풀어내기 위해서다. 다행히 참고할..
