햣

all21개

/:frontend

유한 상태 기계(FSM)를 활용한 채점 추적기 구현

알고리즘 문제 플랫폼에서 제출한 코드가 성공하면 자동 제출하는 기능을 만드는데, 채점 상태를 추적하기 위한 Tracker가 필요했다. Tracker는 채점관련 이벤트를 받고 현재 상태와 받은 이벤트에 따라 상태를 전이한다는 점에서 FSM(유한 상태 기계)를 적용하면 좋겠다는 생각이 들었다. 안타깝게도 오토마타 강의를 듣지 않아서 유한 상태 기계가 뭔지 공부

/:frontend

[JS] Debounce와 Throttle

디바운스와 쓰로틀링은 이벤트의 발생 빈도를 제한하여 최적화하는 기법이다. 두 기법이 뭔지, 차이점은 뭔지 알아보자. Debounce(디바운스) 먼저 바운싱이란 용어는 전자공학에서 기계적인 접점을 가진 스위치에서 접점이 붙거나 떨어지는 그 짧은 순간에 고속으로 여러번 on/off 되는 현상을 말한다. 한 번만 on/off가 발생하길 원하는데 불필요한 인풋이

/:frontend

Vanilla Javascript로 구현하는 SPA - 상태관리 시스템

필요성 이전에 만들었던 컴포넌트를 사용하다보면 한가지 문제점이 발생한다. 자식 컴포넌트들끼리 상태 공유가 필요하면, 그 상태가 공통 부모까지 끌어올려져야 한다. 이 문제를 props drilling 문제라고 한다. React에서도 똑같은 문제가 발생한다. 문제에 대한 해결법 중 하나가 중앙 집중식 저장소를 사용하는 것이다. 상태를 컴포넌트 외부에 둠으로써

/:frontend

Vanilla Javascript로 구현하는 SPA - 컴포넌트 만들기

발단 새로운 프로젝트가 '웹 페이지'보다는 '어플리케이션'에 가까웠으면 했기에 SPA로 개발되면 좋을 것 같다고 생각했다. 이전에 React를 사용해봤었기 때문에 또 React를 사용하면 수월하게 개발할 수 있었지만, 프로젝트 크기가 작아서 React로 개발해봤자 뭔가 새로 배울게 없을 것 같았다. 그래서 "프로젝트 규모가 작으니까 vanilla javas

/:frontend

[JS] 옵저버 패턴 (Observer Pattern)

옵저버 패턴? 옵저버 패턴은 객체의 상태 변화를 관찰하는 옵저버들의 목록을 객체에 등록해서 상태 변화가 발생할 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 즉, 어떤 객체의 상태가 변하면 연관된 객체들에게 알림을 보내는 디자인 패턴이다. 이 패턴의 핵심은 상태를 가진 객체(subject)인 '발행기관(publ

/:frontend

[JS] 이벤트

이벤트(event)는 무언가 일어났다는 신호다. 브라우저에서의 이벤트는, 예를 들어, 사용자가 버튼을 클릭했을 때나 웹페이지가 로드 되었을 때 같은 것이다. 모든 DOM 노드는 이런 신호를 만들어 낸다. 이벤트는 일반적인 제어 흐름과는 다른 접근 방식이 필요하다. 이벤트가 발생하면 누군가 이를 감지해서 처리해주어야 한다. 브라우저는 이벤트를 감지할 수 있으

/:frontend

[JS] 프로미스(Promises)

비동기 동작 많은 프로그램들은 바깥 세상에 있는 것들과 상호작용을 한다. 네트워크를 통해 무언가 요구할 수도 있고, 하드디스크에서 뭔가 들고올 수도 있다. 필요한 것들을 요청한 후, 이것들을 받을 때까지 기다려야 받은 것에 대한 추가작업이 가능할 것이다. 요청에 대한 기다림을 처리하는 방법에는 크게 두 가지 모델이 있다. **동기 모델(synchronous