REACT13 리액트가 클래스 컴포넌트를 버린 이유 목차1️⃣ 리액트에선 과정보단 결과다2️⃣ 3초 뒤의 this.state는 과연 믿을 만한가?3️⃣ 클래스 컴포넌트에서는 함수가 데이터 흐름에서 소외된다4️⃣ 클래스 컴포넌트의 라이프사이클은 '의도'보다는 '타이밍'에 집중한다5️⃣ Hooks는 합성과 재사용성을 극대화한다6️⃣ 클래스 컴포넌트는 미래가 없다 1️⃣ 리액트에선 과정보단 결과다React는 처음부터 지금까지 선언형 UI를 지향해왔다. 중요한 건 어떻게 그 목적에 도달했는가가 아니라, 무엇을 보여주고 싶은가다. "과정보다 결과가 중요하다"는 철학 아래, 복잡한 절차를 감추고 UI를 단지 상태의 결과로 표현하는 방향으로 발전해왔다. 그런데 클래스 컴포넌트는 이러한 철학에 조금 부합하지 않는다. 다음 두 코드는 결과적으로 같은 UI를 표시하지만, .. 2025. 4. 19. Optimization(1): Throttle & Debounce 목차- 소개- ResizablePanel: Observer 패턴 + Throttle- Player: Debounce로 효율적인 이벤트 처리- Search: 사용자 입력에 최적화된 Debounce0. 소개현재 진행중인 프로젝트는 Spotify에 가사 퀴즈 기능을 추가한 애플리케이션이다. 이번 프로젝트에서는 Frontend에서 다양한 최적화 기법들을 적용해 봤는데, 이것들을 시리즈로 정리해보려고 한다. 이번 글은 이 시리즈의 첫 번째 글로, 프로젝트 곳곳에 적용된 Debounce와 Throttle 기법을 다뤄보고자 한다. Optimization Series (업데이트 시 링크 추가 예정)(1) Debounce & Throttle(2) Caching strategy(3) Optimistic update us.. 2024. 12. 5. [WebSocket] 비정상 종료 핸들링 전략 의도적으로 연결을 끊는 상황을 제외하고 비정상적으로 웹소켓 연결이 끊어졌을 때 재연결하는 로직이 없다면 사용자 경험에 치명적일 것이다. 대략적인 class 구조는 다음과 같으며, 하나씩 채워보자. c.f) secondary token 관련해서는 다음 글을 참고하자 => https://hwanheejung.tistory.com/43 import SockJS from 'sockjs-client'; import { Client, StompSubscription } from '@stomp/stompjs'; class WebSocketClient { constructor(url) { this.url = url; this.client = null; // 추가 } async getSecondaryToken() { /.. 2024. 7. 31. [WebRTC] 다대다 화상회의: OpenVidu를 도입하기까지의 자료조사 목차- Short Review- 1:1 통신- 그럼 다대다 화상회의는?- Kurento- Openvidu - 디스코드 클론코딩 1. Short Review - 1:1 통신지난번엔 WebRTC로 1:1 화상회의가 구현되는 flow를 정리해 봤다. 간단하게 복습해 보자. WebRTC: 화상 회의를 구현하는 방법목차- 프롤로그- WebRTC의 동작 원리- Signaling Flow - 마치면서 1. 프롤로그채팅을 구현하기 위해서는 지속적인 연결을 유지하는 웹소켓을 사용한다. 웹소켓에서는 A가 B에게 채팅을 보낼 때 두 사hwanheejung.tistory.com 1.1. 연결이 수립되기까지의 Flow크게 SDP Offer/Answer 과정과 ICE Candidate 교환 과정으로 나눌 수 있다. 이 두 과정.. 2024. 7. 21. [Next.js] Data Mutation: Server Actions 1. Server ActionsNext.js의 server component는 hydrate되지 않은, 즉 interactive하지 않은 컴포넌트로 useState, useEffect 없이 데이터를 불러올 수 있다. 데이터를 변경시켜야 하는 상황에서는 server actions를 사용하면 API route 없이 서버 측에서 직접 DB에 접근할 수도 있고, 페이지 렌더링 과정에 참여하게 된다. 기존에 browser -> (front server ->) backend server -> DB 의 구조를 browser -> front server -> DB로 줄인 것이다. 장점- network 요청 수를 줄일 수 있다- SEO 향상- 민감한 데이터를 클라이언트 측에 노출시키지 않고 처리할 수 있다- client.. 2024. 7. 16. [WebRTC] 화상 회의를 구현하는 방법 (1:1) 목차- 프롤로그- WebRTC의 동작 원리- Signaling Flow - 마치면서 1. 프롤로그채팅을 구현하기 위해서는 지속적인 연결을 유지하는 웹소켓을 사용한다. 웹소켓에서는 A가 B에게 채팅을 보낼 때 두 사용자가 직접 연결되어 있는 것이 아니라 서버의 중개를 통해 대화를 나누게 된다. 그러니까 A가 채팅을 보내면, 서버로 전송되고, 서버는 해당 채팅방을 구독하고 있는 사용자들에게 메시지를 보내주는 것이다. 이 방식은 클라이언트의 수가 늘어날수록 서버에게 큰 부담이 된다. 간단한 텍스트를 보낼 때는 오버헤드가 작을 수도 있지만, 주고받는 데이터가 영상이나 오디오처럼 용량이 크다면 서버의 부담이 엄청날 것이다. WebRTC(Web Real-Time Communication)는 서버의 중개 없이 클.. 2024. 7. 5. 이전 1 2 3 다음
