전체 글

프론트엔드 환경에서 API 동작을 모킹하는 것은 여러 가지 이유로 필요해진다. 프론트엔드의 동작은 필연적으로 백엔드 API와 강한 의존성을 가지게 되기 때문이다. 그런데 우리는 생산성을 높이기 위해 백엔드와 독립적인 환경에서 개발을 하고 싶다. 만약 서버 요청이 들어가는 페이지의 e2e 테스트를 짜고 싶다면? 백엔드 개발이 완료되기 전에 프론트엔드 개발에 착수한다면? 개발 서버의 특정 API에서 에러가 나고 있어 프론트엔드 개발이 블로킹된 상황이라면? 위와 같은 케이스는 API단을 모킹하는 수고를 들일 만한 충분한 이유가 될 것이다. 특히 두 번째 이유는 꽤나 자주 일어나는 일인데, 보통 프로젝트를 시작할 때 프론트엔드와 백엔드가 동시에 개발에 착수하곤 하기 때문이다. 서비스 런칭 데드라인은 가까워질 터..

터미널을 자주 사용한다면 한번쯤 생각해봤을 것이다. 커멘드라인으로 터미널에서 직접 IDE를 실행할 수 있다면 정말 편할 텐데! 그래서 써보는 아주 간단한 웹스톰 커멘드라인 적용법. 웹스톰 커멘드라인 실행환경 만들기 1. 우선 웹스톰을 실행한다. 2. Tools > Create Command-line Launcher 3. 환경변수에 웹스톰 경로를 설정하라는 팝업을 확인할 수 있다. 4. 설정 파일에 들어가서 다음과 같이 PATH 환경 변수에 Webstorm 실행 파일의 경로를 추가해준다. # zsh을 사용한다면 vim ~/.zshrc # bash를 사용한다면 vim ~/.bash_profile export PATH="/Applications/WebStorm.app/Contents/MacOS:$PATH" 5..

팀 단위로 협업을 하는 환경에서는 코드 포맷팅(code formatting)이나 린트(lint) 등 코드 수정이 발생할 때마다 지켜져야 하는 규칙들이 존재할 것이다. 이런 코드 스타일은 세팅파일을 읽어와서 개개인의 에디터에서 직접 자동으로 적용되도록 설정해둘 수 있다. 그러나 Error 또는 Warning이 발생하더라도 코드 자체를 커밋하고 푸시하는 것에 제한이 걸리지 않는다면, 규칙없이 작성된 코드가 머지되고 배포될 가능성이 생긴다. 이를 방지하기 위해 Pull Request를 통해 코드를 머지하는 시점에 해당 규칙을 검사하도록 CI 파이프라인을 만들 수도 있겠다. 그러나 워크플로우를 돌리기 위한 별도의 서버 자원을 사용하고 관리해야 한다는 점, 그리고 소스의 커밋, 푸시가 이미 완료된 시점에서 그 다..

모던한 환경에서 자바스크립트를 사용하는 개발자라면 흔히 npm을 사용해보았을 것이다. 자바스크립트 패키지들을 한 프로젝트에서 사용할 수 있도록, 그리고 누구나 배포할 수 있도록 만들어진 패키지 매니저가 바로 npm이다. node.js에 기본으로 내장된 패키지매니저인 만큼 점유율이 가장 높기도 하다. 그러나 사용하다보면 여간 불편한 점들이 존재하기 마련이다. 특히 package.json을 통해 생성하는 node_modules는 관리하기가 상당히 까다롭다. 본 포스팅에서는 npm의 문제점을 짚어보고, 대안으로 등장한 yarn berry의 개념 및 간단한 사용법을 알아보고자 한다. npm의 문제점 npm으로 만들어진 프로젝트에는 크게 package.json, package-lock.json, 그리고 거대한 n..

리액트에서 form을 다루기 위해 input 태그를 쓸 때, 흔히 볼 수 있는 에러가 있다. 바로 uncontrolled input이 controlled input으로 바뀌었다는 내용의 에러다. 콘솔에서 친절(?)하게 알려주고 있듯이, 초기값이 undefined 였다가 렌더링 후에 값이 들어와 defined value로 바뀌면서 에러가 발생하게 된다. 이 가이드에 따르면, input 태그를 일반적으로 사용하기 위해서는 value에 undefined가 들어가면 안 된다. 따라서 초기값이 존재하지 않을 경우, undefined가 아닌 공백(””)을 줘서 controlled input으로만 사용하도록 바꿔주면 에러를 방지할 수 있다. 그렇다면 여기서 말하는 controlled input이란 무엇일까? Cont..