[Javascript] MVVM: 화면과 값을 묶어 두면 무엇이 편해지고 무엇이 어려워지는가
MVC, Flux, Redux를 공부하고 나서 이런 질문이 남았다. 「MVVC인가? 그런 것도 있지 않아?」 이름을 정확히 기억하지 못했는데, 말하려던 건 MVVM(Model-View-ViewModel)이었다. 끝 글자가 C가 아니라 M이다.
Javascript
[Javascript] Bulletproof React: 층을 셋으로 줄이면 FSD에 비해 무엇을 얻고 무엇을 잃는가
FSD 글(화면 코드를 층으로 나누는 구조 FSD를 공부한 글)의 결론은 가설 하나였다. 「폴더는 지금 표준대로 두고, 『아래는 위를 못 부른다』는 방향 규칙만 가져온다.」 그리고 확인하지 못한 것 셋을 남겼는데, 그중 하나가 「무엇으로 막나」였다. 자바는 private이나 같은 ...
[Javascript] Redux: Flux에서 무엇을 덜어 냈고, 왜 이전 상태를 고치지 않는가
Flux 글에서 「값을 바꾸고 싶으면 전표(Action)를 내고, 고치는 건 값을 가진 Store가 한다」를 공부했다. 그다음에 궁금했던 건 두 가지였다. Flux와 Redux는 같이 나온 건가, 다른 때 나온 건가. 그리고 Redux는 Flux와 무엇이 다른가.
[Javascript] MVC: 프론트엔드에서 MVC는 어디로 갔는가
FSD 글에서 프론트엔드 구조 후보 넷을 놓고 FSD를 골랐다. FSD는 화면 코드를 층으로 나누고 「위층 파일만 아래층 파일을 불러 쓸 수 있다」는 방향 규칙을 거는 구조다. 그때 MVC는 「화면과 로직을 나누나에 답할 뿐, 누가 누구를 부르나에는 답이 없다」는 한 줄로 넘겼다....
[Javascript] Flux: 값을 바꾸는 문을 하나로 줄이면 무엇이 달라지는가
MVC 글은 Flux라는 이름을 꺼낸 데서 끝났다. 큰 MVC 앱에서는 값 하나를 바꾸면 그 값에 기대는 다른 값이 줄줄이 바뀌고, 결국 「누가 이걸 바꿨지?」를 찾을 수 없게 됐다. Facebook은 그 답으로 Flux를 내놓았다. 그 글에는 「Flux가 실제로 어떤 모양인지는 ...
[Javascript] Feature-Sliced Design: 프론트엔드에도 계층 구조가 있는가
백엔드, 그러니까 화면 뒤에서 데이터를 저장하고 업무 규칙을 처리하는 서버 쪽 프로그램에는 3계층 구조가 있다. Controller → Service → Repository 순서로만 부르고, 거꾸로는 부르지 않는다. 더 나아가면 헥사고날 아키텍처가 있다. 업무 규칙을 가운데 두고 ...
[JavaScript] 프론트엔드 API 관리 전략: 유지보수 가능한 구조 설계하기
프론트엔드 프로젝트가 커지면서 가장 먼저 복잡해지는 부분이 API 호출 관리입니다. 처음엔 간단하게 컴포넌트에서 직접 fetch나 axios(fetch와 같은 역할을 하는 또 다른 HTTP 요청 라이브러리)를 호출하다가, 어느 순간 같은 API를 여러 페이지에서 중복 호출하고, A...
[JavaScript] 프론트엔드 API 호출의 변천사: Form Submit에서 Fetch API까지
현대의 웹 개발자라면 당연히 사용하는 API 호출. 하지만 이 기술이 어떻게 진화해왔는지, 그리고 왜 현재의 형태로 정착하게 됐는지 생각해본 적 있나요?
[JavaScript] jQuery + Proxy로 구현하는 리액티브 상태 관리
2010년대 초반 jQuery는 웹 개발의 표준이었습니다. 하지만 시간이 지나면서 React, Vue, Angular 같은 현대적 프레임워크들이 등장했고, 그들은 “상태가 변경되면 화면이 자동으로 업데이트된다”는 혁명적인 개념을 제시했습니다.