CSS 변수의 기본 동작부터 React 환경에서의 활용, 반응형/다크모드 적용까지
React로 만든 웹사이트를 로컬에서 완성했더라도, 사용자가 언제 어디서나 빠르고 안정적으로 접속하려면 **배포**가 필요합니다. 배포 플랫폼은 다양하지만, 이번 글에서는 **AWS S3 + CloudFront** 조합을 사용합니다.
수상한 녀석들은 광고 공모전 탈락작을 학습 자산으로 전환하는 플랫폼입니다. 이러한 문제의식에서 출발한 프로젝트였고, 저는 이 프로젝트에서 프론트엔드 개발을 맡았습니다. 그런데, 화면을 구현하던 중 예상치 못한 문제가 발생했습니다
타입스크립트를 공부하면서 가장 먼저 부딪히는 질문 중 하나는 type과 interface의 차이점은 뭔가요?입니다. 이 두 문법은 겉보기엔 비슷하지만, 의외로 세세한 차이점과 철학적인 배경이 존재합니다.
현대 웹 애플리케이션은 대부분 서버나 외부 API로부터 데이터를 가져와 사용자에게 보여주는 구조를 가지고 있습니다.
이번 글에서는 NestJS에서 TypeORM을 연동하고, **환경변수를 안전하게 관리**하기 위해 `@nestjs/config`과 `Joi`를 활용하여 **유효성 검증을 추가하는 방법**까지 실습해본 내용을 정리해보겠습니다.
NestJS는 객체지형, 함수형, 함수형 반응형 프레임워크를 결합한 **의연성 주입 기반의 Node.js 백엔드 프레임워크**입니다. 이 프레임워크는 타입 기반 개발을 지향하고 있으며, API 개발 시 입력값 검사과 타입 변환을 중요한 기본 기능으로 포함하고 있습니다.
Chrome 확장 프로그램의 백그라운드 서비스에서 발생하던 상태 불일치 문제를 해결하기 위해 싱글턴 패턴과 의존성 주입을 도입하여 리팩토링을 진행했습니다. 기존에는 서비스가 서로 독립적으로 동작하며 서로 다른 상태를 참조하거나 초기화 순서가 뒤엉키는 문제가 있었습니다. 이를 해결하기 위해 서비스 전역에서 단일 인스턴스를 유지하고, 명확한 초기화 흐름을 갖춘 구조로 개선했습니다.
VOIM 익스텐션은 한국대학생IT학회 8팀에서 개발한, 약시 사용자들의 웹 접근성을 개선하기 위한 크롬 확장 프로그램입니다.
안녕하세요! 저는 시각 정보 해독이 어려운 사용자를 위한 크롬 확장 프로그램인 Voim의 프론트엔드 개발자 최호입니다. 저희 프로젝트 VOIM은 약시 등 시각 약화 사용자들이 웹 콘텐츠를 더 쉽게 이해할 수 있도록 돕는 다양한 기능을 제공합니다.
예시 게시물입니다.
OSSCA에 참여하게된 계기는 막연한 오픈소스에 대한 환상과 프론트엔드 개발자로서 브라우저에 관해 자세히 알고 싶었기 때문입니다. 그리고 활동을 하며 작지만 제겐 의미있는 첫 커밋을 하게 되었습니다. 그에 대한 이야기를 해볼까합니다.
크롬 익스텐션을 개발을 할때 background, popup, content script 간의 메시지 통신을 다루는 것은 필수적이다. 그런데 팝업과 사이드 패널이 아닌 웹페이지 안에 내 익스텐션의 창을 띄우고 싶다면 두 가지 방법이 있을것이다.
1번 코드에서는 Error로 에러 객체를 생성한게 부족했다. 1번 코드처럼 에러처리를 하게 된다면
개발을 하다 보면 코드가 점점 복잡해지고, 유지보수가 어려워지는 순간을 맞이하게 되는 경우가 많다. 특히 규모가 있는 프로젝트이거나 협업을 진행할수록 이런 문제는 자주 발생하게 된다. 이런 상황에서 코드의 품질을 유지하고 확장성과 유지보수성을 높이기 위한 설계 기준이 필요하며, 대표적인 예로 SOLID 원칙이 있다.
싱글톤 패턴은 애플리케이션 내에서 특정 클래스의 인스턴스를 단 하나만 생성하고, 이를 전역에서 공유 할 수 있도록 하는 디자인 패턴이다. 즉, 한 번 생성된 인스턴스는 계속 재사용되며, 새로운 인스턴스가 생성되지 않는다.
Next.js는 **표준 빌드(Standard Build)**와 **전체 정적 빌드(Full Static Build)** 두 가지 방식으로 배포할 수 있다.
개발자로서의 성장에 대한 고민이 많아 요즘 많은 현직자분들과 얘기를 나누고 있다. "더 성장하려면 무엇을 배워야 할까?" "현재 내 프론트엔드 실력을 객관적으로 점검하는 방법은 무엇일까?" "다음 단계로 나아가려면 무엇을 해야 할까?"와 같은 질문을 던지며 방향을 찾아가고 있다.
Next.js에서는 애플리케이션의 모든 페이지가 React 컴포넌트로 이루어져 있지만, 기본적으로 HTML의 <html>, <head>, <body> 태그 같은 구조는 자동으로 생성됩니다. 하지만 때로는 이러한 구조를 커스터마이징할 필요가 있을 때가 있습니다. 바로 이때 사용하는 파일이 _document.js입니다.
웹에서 인증은 필수적인 기능이다. 사용자의 데이터를 보호하고, 로그인한 사용자만 특정 기능을 이용할 수 있도록 제한하는 것이 중요하다.
강의를 듣다 저번 Nextjs 프로젝트 할때 가장 어려웠던 서버 컴포넌트와 클라이언트 컴포넌트에 대한 내용이 나왔다. 넥스트로 프로젝트를 처음해봤어서 편하다는 이유로 최상단 루트에 클라이언트 컴포넌트를 선언하고 개발을 진행했다. 그리고 개발이 다 끝나고 나서야 알았다. 이게 얼마나 멍청한 짓이였는지를..
Loader와 Action이 나오기 전인 React Router DOM v6.4 이전에는 라우팅과 데이터 페칭이 완전히 분리되어 있었습니다. 라우터는 단순히 URL에 따라 어떤 컴포넌트를 렌더링할지만 결정했고, 데이터 로딩은 각 컴포넌트의 책임이었습니다.
이번 프로젝트는 SK 그룹 개발자 커뮤니티인 DEVOCEAN의 영(Young), 오픈랩에서 진행된 다양한 프로젝트들을 기록하고 소개하는 웹사이트를 만드는 것이 목적이었습니다. 단순한 프로젝트 리스트를 나열하는 것이 아니라, **브랜드의 철학과 생명력을 전하고자 했습니다.**
마이페이지의 활동 대시보드에는 게시글을 한 번도 작성하지 않은 사용자는 **랭킹을 확인할 수 없는 화면**을 보게 되는 화면이 있었습니다.
프론트엔드를 처음 배울 때부터 저는 React로 개발을 시작했습니다. HTML, CSS, JavaScript의 기초를 어느 정도 익힌 뒤 곧바로 React 컴포넌트를 만들고, 상태를 useState로 관리하며, 화면을 JSX로 선언하는 방식이 자연스러웠습니다.
웹 서비스에서는 사용자 활동을 날짜별로 보여줘야 할 일이 종종 있습니다. 단순히 달력만 보여주는 것으론 부족하고, **어떤 날짜에 어떤 활동이 있었는지를 시각적으로 구분**할 수 있어야 하죠.
인기 글을 불러오는 중...
🌀 댓글을 불러오는 중...
Howu Run
