REACT

이번 글은 진행하는 프로젝트에 Storybook을 이용해 컴포넌트의 UI를 테스트하며 개발을 진행하는 컴포넌트 주도 개발법 CDD를 적용하며 정리하기 위해 작성했다.CDD는 컴포넌트를 모듈 단위로 나누어 개발하며 전체적인 UI 개발을 진행하는 개발 및 설계 방법론 이다.컴포넌트 단위로 시작해 전체 UI를 구성하기 위해 점진적으로 개발해 나아가는 Bottom-UP 성향을 갖고있다.Storybook을 이용한 CDD는 UI 디자인을 체계적으로 개발 디자이너와의 효율적인 협업을 UI 컴포넌트 익스플로어 툴을 이용해 진행할 수 있다. 문서화된 컴포넌트의 UI를 CSS, JS, 단위 테스트 등 UX에 영향을 줄 수 있는 요소들의 테스트도 가능하다. 기초 사용법우선 Storybook의 기본적인 사용법에 대해 알아보자..

나는 IT 학원에서 학생들을 대상으로 FE 강사를 하고있다. 물론 React와 같은 프레임워크 강의를 진행하지 않지만, HTML, CSS, JS, Python 등 기초 웹 프론트엔드와 언어들을 강의하고있다. 최근 한 학생이 물어본 HTML의 iframe 태그에 대해 정리하고자 이 글을 사용한다. 학생의 질문은 다음과 같다.현제 프로젝트에서 iframe을 이용해 다른 웹 사이트를 띄우려고 하는데, 인스타그램을 비롯한 많은 서비스에서 iframe을 통한 접근을 금지하는데 왜 금지하는가? 라는 질문이였다. 프론트엔드 강사라는 사람이 해당 질문에 대한 답을 제대로 하지 못했다...... 학생에게 정말 미안한 마음이다...  iframe이란?iframe 태그는 HTML 문서내에서 또 다른 HTML 문서를 삽입할 ..

에러React 애플리케이션을 CRA를 이용하지 않은 프로젝트를 만들던 중 컴포넌트를 import 하던 중 아래의 사진과 같은 에러가 발생했다.에러 코드를 읽어보니 webpack 번들링 중 발생한 에러로서 import 해오는 주소를 절대주소로 가져오는 코드에서 발생한 에러 처럼 보인다.import Test from 'components/Test';import React from 'react';import { Route, Routes } from 'react-router-dom';function App() { return ( }> }> );}export default App; 위의 'components/Test' 에서 './c..

CRA를 사용하지 않으려는 이유CRA(Create-React-App)을 사용하면 빠르게 React 프로젝트를 설정할 수 있다. npm create-react-app my-app 명령어 한줄로 프로젝트에 필요한 기본 패키지가 모두 설치되고 설정 파일이 모두 자동으로 생성되고 기초 파일까지 생성된다. 이렇게 편한 사용법을 이유로 지금까지 진행했던 프로젝트에서 많이 사용했다. 하지만 분명 편리한 방법이지만 한계점이 분명히 존재한다. 프로젝트의 방향성에 따라 프로젝트의 기존 설정을 변경해야할 때가 존재할 수 있다. CRA를 이용해 생성된 React 앱은 하나의 build 의존성을 갖고 모든 패키지와 설정 정보를 다른 곳에 보관하고 있다. 이로 인해 Webpack, Babel, Typescript 등의 ..

이전 글들 중 유지보수가 편리한 코드를 만드는 강좌의 정리글을 올린적이 있다. 내가 구현한 코드를 보던 중 너무 의존성이 강하게 묶여있는 코드를 발견해 이를 리팩토링 하는 기록을 남기고자 한다. 코드 const ShowPosition = ({ positions, tyleInfoSetFun, operatorImgData }: positionsInterface) => { const ePositions = positions.map(e => e.ePosition); // 객체형으로 선택됬는지 여부를 보관하기 const [selectedState, setSelectedState] = useState({ position: { duelist: false, recon: false, sentinels: false, co..

문제의 발단은 이러하다. 개발한 컴포넌트에서 필요 이상의 API 요청이 발생하는 것이 문제이다. 파악한 문제는 2가지 이며 천천히 문제의 원인과 해결 방법에 대한 설명을 작성하겠다. 1. API 요청 방식 이 문제가 가장 근본적인 원인이였다. 기존 코드는 특정 컴포넌트를 클릭하면 그 컴포넌트에 맞는 데이터를 요청하는 방식으로 설계했다. 그로인해 같은 데이터라도 다시 다른 컴포넌트를 클릭했다가 과거의 컴포넌트를 눌러도 같은 API 요청이 발생하게 된다. 이러한 방식은 다른 프로젝트나 컴포넌트 개발시 큰 데이터 혹은 서버의 상태에 따라 원활한 서비스 제공이 어려울 것이라 판단했다. 이 문제는 각각 API 요청을 하던 로직을 초기 렌더링시 다수의 데이터를 병렬로 요청해 처리하도록 했다. 기존 코드 // 해당 ..