전체 글

이 글은 동글이 반응형을 도입한 과정입니다. 1. 도입 계기 첫 배포를 마친 동글이 서비스로서 성공하려면 사용자가 있어야 한다. 그래서 다양한 루트로 홍보를 진행했는데, 페이스북 노션 그룹, 블로그, 카페, 카카오톡 오픈채팅방, 에브리타임, 인스타그램 등 많은 환경에서 홍보를 진행했다. 이전 글에서 확인할 수 있듯이 동글은 원래 PC 타깃으로 개발되었다. 하지만 카카오톡, 에브리타임, 인스타그램 등으로 유입된 사용자들은 모바일로 들어와서 첫 화면을 본다는 게 문제였고, 그 결과 첫인상이 좋지 않았다. 위 사진 말고도 반응형에 대한 피드백은 상당히 많았고, PC 퍼스트이긴 하지만 이를 계기로 모바일 지원을 고민하게 되었다. 2. 도입 과정 타겟 기기 선정: 휴대폰, 태블릿, PC 반응형을 코드로 작성하기 ..

이 글을 동글에서 낙관적 업데이트를 도입하기까지의 과정을 담은 글입니다. 1. 문제상황 업로드한 글의 제목을 바꿀 때, 정상 응답이 오기 전까지는 수정 전 제목이 보이는 문제가 있었다. 기능을 사용하는 데는 문제가 없지만 사용자는 불편하게 느낄 수 있고, 인터넷이 느린 환경에서는 더욱 문제가 된다. 그래서 요청이 성공했다고 가정하고 응답이 오기 전 요청 결과를 바로 반영하는 낙관적 업데이트 도입을 고민했다. 2. 낙관적 업데이트.. 꼭 필요할까? 그 전략이 좋아보인다고 해서 무턱대고 도입할 수는 없다. 사용자의 데이터 변경 요청을 빠르게 반영할 수 있다는 장점이 있지만, 서비스에 대한 사용자의 신뢰도 하락으로도 이어질 수 있다. 예를 들어 글 제목 변경 요청 후 재빨리 글 발행을 요청했는데 실제로는 글 ..

이 글은 동글을 개발하면서 MSW를 어떻게 하면 잘 활용할 수 있을지 고민하고 적용한 과정에 대한 글입니다. 또한 프론트엔드 개발에서 쓰이는 MSW에 대한 기본적인 이해가 있어야합니다. MSW를 이용해 개발을 해보신 경험이 있다면 더욱 좋습니다. 1. 데이터 모킹의 필요성 프로젝트를 만들면서 어떤 기능를 완성하기 까지는 기획 -> API 논의 -> 백엔드 개발 -> 프론트엔드 개발 -> 배포 의 단계를 거친다. 프론트는 데이터를 받아와서 유저가 보는 부분을 개발하기 때문에, 백엔드에 의존적일 수 밖에 없다. 하지만 공수기간을 맞추려면 마냥 백엔드 기능이 완성되기 까지 기다릴 수는 없다. 이때 API 문서를 보고 데이터를 모킹해서 개발할 수 있다. 2. MSW을 이용하며 마주한 문제 MSW를 이용하면 요청..

이전 렌더링 때보다 더 많은 훅을 렌더링했다는 뜻. 즉 훅의 호출횟수가 일정하지 않다는 뜻이다. 리액트 훅은 컴포넌트 내부 최상위 레벨에 선언해야한다. 즉 훅은 컴포넌트를 제외하고는 다른 블럭({ }) 내부에서 이용해서는 안된다 훅을 다음과 같이 선언하지는 않았는지 확인해보자. // 전부 잘못된 훅 호출 방식이다 // 1. 조건문 안에서 호출 if (someCondition) { useEffect(() => { ... }); } // 1.1 && 연산자 이용하여 조건부 호출 !value && useCustomHook(value) // 2. 반복문 안에서 호출 items.forEach(item => { useEffect(() => { ... }); }); // 3. 이벤트 핸들러나 다른 함수 내에서 호출 ..

해당 글은 우아한테크코스 5기 프로젝트 "동글"의 번들 사이즈를 최적화하면서 겪은 문제와 그 해결과정을 담은 글입니다. 1. highlight.js란? 프로젝트 동글은 글에 존재하는 코드블럭을 이쁘게 스타일링 해주어야 했다. highlight.js 라이브러리를 통해 그 목적을 달성할 수 있다. 2. 개선 이유 동글의 production 번들의 패키지를 bundleAnalyzerPlugin로 분석한 결과 highlight.js가 번들 사이즈의 약 25%(286KB/1180KB)를 차지하고 있었다. 동글은 개발자가 타겟 유저층이므로 코드블럭을 꾸미는 것은 필수 기능에 해당한다. 하지만 너무 큰 사이즈로 인해 로딩이 길어져 사용자 경험에 좋지 않다. 3. 문제 상황 인식 및 해결과정 문제 상황 문제는 high..

1. 번들 사이즈 최적화를 해야하는 이유 프로젝트를 빌드하면 흩어져있던 코드들을 웹팩을 이용해 하나(번들)로 묶을 수 있다. 프로젝트 개발 초기에는 번들의 크기가 작아 괜찮지만, 개발이 진행될수록 번들파일이 커져서 유저들이 번들파일을 다운받기위해 기다리는 시간이 늘어나게 된다. 대기시간이 늘어나면 그만큼 사용자 이탈율도 증가한다. 따라서 적절한 방법을 통해 번들 사이즈를 줄일 필요가 있다. 2. BundleAnalyzerPlugin 적용하기 BundleAnalyzerPlugin은 웹팩으로 만든 번들 파일을 분석해주는 웹팩 플러그인이다. 설치 yarn add -D webpack-bundle-analyzer 설정 웹팩 설정 BundleAnalyzerPlugin은 웹 서버로 실행하거나 빌드할 때 기본적으로 함..

이 글은 동글이 서비스 타겟 환경을 PC로 정한 이유와 브라우저 지원 범위에 대한 글입니다. 1. 서비스 타겟 환경: PC 동글은 블로그에 쓸 글을 업로드(import)하고 올라온 글들을 블로그에 포스팅 하는 서비스이다. 모바일 대응도 할 수는 있겠지만 서비스 특성 상 모바일이 핵심 타겟 환경은 아니라고 생각해서 PC 버전을 우선적으로 지원하기로 결정했다. 2. 브라우저 지원 범위: Chrome, Edge, Whale, Ark 브라우저 지원 범위는 Browser Market Share Worldwide 에서의 브라우저 점유율을 참고하여 정했다. 타겟은 개발이며 주변 개발자가 타겟층이 될 확률이 높기 때문에 한국을 기준으로 잡았다. 크게 Top3인 Chrome, Edge, Whale 을 지원하기로 결정했다..

이 글은 동글이 고민한 웹 접근성과 적용 결과에 관한 글입니다. 1. 개선 할 웹 접근성 선정과 개선 과정 모든 사람들이 동글을 차별없이 동일하게 사용할 수 있도록 웹 접근성을 고려했다. 고려해볼 웹 접근성은 다양한데, 그 중 잘 안지켜지는 웹 접근성 TOP8 중에 동글 서비스에 적용하면 좋은 접근성을 우선으로 선정하여 개선하려고 했다. 동글은 글을 관리하고 발행하는 서비스이기 때문에 그 기능을 제공하는데에 중요한 명도대비, 반복영역 건너뛰기, 키보드 사용보장을 선정했다. 텍스트 컨텐츠의 명도 대비 동글은 글을 봐야하기 때문에 글자와 배경의 명도대비가 중요하다. 또한 시각장애인들이 이용하려면 키보드로만 이용할 수 있어야한다. 웹 컨텐츠 접근성 가이드 라인인 WCAG 2.1 에 따르면, 명도대비가 4.5:..