본문 바로가기

Develop/Frontend 가이드

[Blazor] Blazor WebAssembly + Webpack + TypeScript + Sass 개발 환경 구축 Blazor WebAssembly + Webpack + TypeScript + Sass 개발 환경 구축 Blazor 를 다른 환경과 통합하여 사용하는 예제를 찾을 수 없어, 직접 연구하여 공유합니다. Blazor 와 관련된 자료는 공식 문서 외에 Awesome Blazor 에서 다양하게 찾을 수 있습니다. 1. 프로젝트 생성 위 그림과 같이 Blazor WebAssembly App 프로젝트를 생성합니다. 생성하면 위 그림과 같은 결과를 얻을 수 있습니다. 현재 상태로 빌드해서 실행하면 위 그림과 같은 결과를 얻게 됩니다. 이제 여기서부터 하나하나 환경을 세팅해보도록 합시다. 2. Webpack 추가 node -v npm -v 현재 프로젝트에 Webpack 을 추가하려면 Node.js 를 설치해야 합니다...
[Blazor] Sass 를 적용하는 방법 Sass 를 적용하는 방법 일단 Sass(Syntactically Awesome Style Sheets) 를 한 문장으로 설명하자면, 스타일을 표현하는 CSS 파일을 프로그래밍 언어처럼 만들 수 있도록 하는 확장 언어입니다. 따라서 Sass 파일을 컴파일하면 결과로 CSS 파일을 얻을 수 있습니다. Sass 는 Node.js 를 바탕으로 npm 으로 패키지를 관리하며 React 로 컴포넌트를 만들고 Webpack 으로 번들링하는 FrontEnd 프로젝트에 빈번하게 사용되며, 번들링할 때 Sass 를 컴파일하여 Css 파일로 만든 뒤 최종 번들에 추가하여 사용합니다. Blazor 에서도 마찬가지로 Sass 를 사용하려면, Sass 를 컴파일하고 최종 결과에 추가하는 과정이 필요합니다. 제일 심플한 방법은 ..
[FE] webpack 에서 Source Map 이 동작하는 원리 Webpack 에서 Source Map 이 동작하는 원리 Visual Studio Code 에서 디버깅하려고 break point 를 잡으면 break point 가 활성화가 되지 않거나 엉뚱한 코드에서 break 가 되는 경우을 종종 겪게 됩니다. 개발을 하다보면 이게 꽤 거슬립니다. 일단 디버깅을 제대로 할 수 없으니 런타임에 어떤 데이터가 저장되고 어디서 어떤 함수가 호출되는지를 console.log() 로 파악하는데 이게 너무나도 고역입니다. 그래서 저는 Source Map 이 어떻게 구성되고 동작하는지를 조사했고 이를 공유드리고자 합니다. Source Map 은 개발하는 코드와 번들링된 코드 사이의 관계를 표현하는 데이터입니다. 이 Source Map 이 필요한 이유는 webpack 을 사용해서..
[FE] Web API - WebSocket API Web API - WebSocket API HTTP/1.1 프로토콜은 클라이언트가 TCP 프로토콜로 서버와 연결한 뒤에 요청을 보내고 서버로부터 응답을 받고 나면 연결을 해제하는 프로토콜입니다. 클라이언트가 요청을 보내지 않으면 서버와 연결되지 않기 때문에 서버가 주도적으로 클라이언트와 통신을 시작할 수 없습니다. 그래서 서버가 클라이언트에게 무엇인가 알려주고 싶어도 방법이 없습니다. 서버 내부적인 변경을 감지할 수 없는 클라이언트가 서버가 원하는 걸 눈치채고 요청을 보내는건 불가능합니다. 그래도 이를 해결하고자 여러 방법이 시도되었습니다. 먼저, 클라이언트가 일정 주기로 서버에게 변경사항이 있는지 확인하는 방법이 제일 직관적이고 구현이 간단합니다. 하지만, 이 방법은 현업에서 사용될 수 없는 방법입니다..
[FE] Web API - Client-side storage : Service Worker API & Cache Web API - Service Worker API & Cache Service Worker 와 Cache 를 활용하면 인터넷 연결이 끊겨도 동작하는 앱을 만들 수 있습니다. Service Worker 는 브라우저에 등록되어, 브라우저와 네트워크 사이에서 프록시 서버의 역할을 수행합니다. 즉, Service Worker 는 서버인 것처럼 브라우저가 서버에게 보내는 요청에 응답할 수 있습니다. Cache 는 브라우저의 Request 와 서버의 Response 를 저장할 수 있습니다. 오프라인에서 동작하는 앱을 만들려면, 먼저 Service Worker 를 등록합니다. 그리고 인터넷이 연결되어 있는 동안, 브라우저가 보내는 Request 와 Response 를 Cache 에 저장합니다. 그리고 인터넷 연결이..
[FE] Web API - Client-side storage : IndexedDB Web API - Client-side storage 브라우저 환경에서 데이터를 저장하는 방법을 시리즈 글로 소개하고 있습니다. IndexedDB IndexedDB 는 클라이언트에 데이터를 저장하는 방법 중 하나입니다. 따라서 네크워크 연결 여부와 관계없이 데이터를 활용할 수 있어, 모바일 플랫폼의 웹 앱에서 활용하기 좋습니다. IndexedDB 는 Cookie 나 localStorage 와 sessionStorage 와 달리 복잡한 데이터를 저장하기 위한 목적의 저장소입니다. 그래서 원리나 사용하는 방법도 다른 저장소에 비해 복잡합니다. 1. IndexedDB 초기화한다. 쿠키는 서버의 Set-Cookie 헤더에서 설정하고 localStorage 와 sessionStorage 는 사용하는 순간 저절로 ..
[FE] Web API - Client-side storage : 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage Web API - Client-side storage 브라우저 환경에서 데이터를 저장하는 방법을 시리즈 글로 소개하고 있습니다. 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage 는 쿠키 Cookie 처럼 브라우저 내에서 Key/Value 로 데이터를 저장할 수 있는 저장소입니다. 로컬 스토리지와 세션 스토리지는 쿠키의 한계를 극복하기 위해 HTML5 와 함께 도입되었습니다. 쿠키는 오래동안 함께 했기에 익숙하고 사용하기 편리한 만큼 여러 한계를 가지는데 대표적인 한계로 서버가 허용하는 HTTP 헤더 크기 이상으로 쿠키에 데이터를 저장할 수 없다는 점입니다. HTTP 프로토콜 설계는 헤더의 ..
[FE] Web API - Client-side storage : 쿠키 Cookie Web API - Client-side storage 브라우저 환경에서 데이터를 저장하는 방법을 시리즈 글로 소개하고 있습니다. 쿠키 Cookie 과거부터 지금까지 사랑받고 있는 방법은 쿠키 Cookie 입니다. 원래 HTTP 프로토콜은 Stateless 한 프로토콜로 과거 통신 상태를 기록하지 않는 프로토콜입니다. 따라서 순수한 HTTP 통신만으로는 클라이언트를 구분하여 반응하거나 클라이언트 상태에 따라 대응할 수 없습니다. 즉 어떤 클라이언트이던지 동일한 요청에 동일한 응답을 합니다. 하지만 현실적으로 클라이언트로부터 오는 요청을 상태에 따라 다르게 처리할 방법이 필요했습니다. 예를 들어, 서버가 클라이언트로 받는 요청이 로그인한 사용자가 보낸 요청인지 아닌지를 판별하거나, 동일한 클라이언트로부터 오..

티스토리툴바