[Javascript] Bulletproof React: 층을 셋으로 줄이면 FSD에 비해 무엇을 얻고 무엇을 잃는가
FSD 글(화면 코드를 층으로 나누는 구조 FSD를 공부한 글)의 결론은 가설 하나였다. 「폴더는 지금 표준대로 두고, 『아래는 위를 못 부른다』는 방향 규칙만 가져온다.」 그리고 확인하지 못한 것 셋을 남겼는데, 그중 하나가 「무엇으로 막나」였다. 자바는 private이나 같은 ...
[Javascript] Redux: Flux에서 무엇을 덜어 냈고, 왜 이전 상태를 고치지 않는가
Flux 글에서 Flux를 공부했다. Flux는 「값을 바꾸고 싶으면 전표(Action)를 내고, 고치는 건 값을 가진 Store가 한다」는 방식이다. Action은 「좋아요가 반영됐다」처럼 무엇이 일어났는지 적은 객체이고, Store는 화면이 보여줄 값을 들고 있는 객체다. 이 ...
[Javascript] MVC: 프론트엔드에서 MVC는 어디로 갔는가
FSD 글에서 프론트엔드 구조 후보 넷을 놓고 FSD를 골랐다. FSD는 화면 코드를 층으로 나누고 「위층 파일만 아래층 파일을 불러 쓸 수 있다」는 방향 규칙을 거는 구조다. 그때 MVC는 「화면과 로직을 나누나에 답할 뿐, 누가 누구를 부르나에는 답이 없다」는 한 줄로 넘겼다....
[Javascript] Flux: 값을 바꾸는 문을 하나로 줄이면 무엇이 달라지는가
MVC 글은 Flux라는 이름을 꺼낸 데서 끝났다. 큰 MVC 앱에서는 값 하나를 바꾸면 그 값에 기대는 다른 값이 줄줄이 바뀌고, 결국 「누가 이걸 바꿨지?」를 찾을 수 없게 됐다. Facebook은 그 답으로 Flux를 내놓았다. 그 글에는 「Flux가 실제로 어떤 모양인지는 ...
[Javascript] Feature-Sliced Design: 프론트엔드에도 계층 구조가 있는가
백엔드, 그러니까 화면 뒤에서 데이터를 저장하고 업무 규칙을 처리하는 서버 쪽 프로그램에는 3계층 구조가 있다. Controller → Service → Repository 순서로만 부르고, 거꾸로는 부르지 않는다. 더 나아가면 헥사고날 아키텍처가 있다. 업무 규칙을 가운데 두고 ...