240216_mvc_api.md

노코드 프로그래밍의 기반으로 사용되는 라이브러리인 rete js의 구조 자체가 사실 MVC 패턴인데, 우리는 이 중 Control 부분의 역할을 SidePanel로 분리하여 수행하도록 하고 있다고 볼 수 있습니다.

역할		동작
Model	노드 데이터	데이터 저장	데이터 업데이트
	⬇️ 저장된 데이터 전달	⬆️ 사용자 입력값 전달
Control	인풋 컴포넌트	저장된 데이터 표시	사용자 입력값 받기
	⬇️ 저장된 데이터 전달
Component	노드 UI	노드 정보 및 연결 구조 가시화

문제상황 1 - 거대한 Control은 또 다른 MVC 패턴을 만든다

Control == SidePanel 이라고 생각했을 때, 분리한 만큼 이 SidePanel의 역할이 점점 커졌고, 단순히 사용자와 interaction 하고 데이터를 전달하는 것을 넘어서서 그 안에서 또 설정된 input 값을 기반으로 api 요청을 보내고, 데이터를 받아와서 화면에 표시해야 하는 정도가 되었습니다.

mvc패턴을 적용한 trainer pannel 화면

컴포넌트가 거대해지는 것을 막고자 api를 호출하고 데이터를 받아오는 함수들을 ContextAPI를 활용해서 꺼내주었습니다. TrainContext가 또다른 Model이 되었습니다. 이 함수들을 호출하는 버튼은 TrainControl이라는 컴포넌트를 만들어 분리해주었고, 받아온 데이터를 감지하고 d3 라이브러리를 활용해서 그래프로 표시하는 TrainResultTab은 View의 역할을 하게 되었습니다.

정리하자면

1. Model: api 통신과 같은 low level 동작 관리, data 관리
2. View: 레이아웃과 화면을 처리
3. Controller: 유저와 직접적인 상호작용, 모델과 뷰에 명령 전달

이렇게 되었습니다.

왜 필요했는데?

제가 train을 위한 노드의 패널(컨트롤)만 이렇게 구성하게된 이유가 있는데요.

유저가 학습 결과를 보기 까지 거쳐야하는 단계에서 필요한 버튼들이 기존에는 여기저기 산재되어 있었습니다. DataConvert 탭에서 train을 하기 위해서 노드들을 pytorch코드로 변환시키고, Train result 탭으로 넘어가 학습을 시작 버튼을 누르고, 학습 결과를 받아오는 과정에서 유저가 마우스를 이곳 저곳 눌러야 했습니다.

그래서 이 버튼들을 한 곳에 모아놓고 유저로 하여금 '버튼을 누르자'는 생각 외에 다른 생각이 들지 않게끔 유도하고 싶었습니다.

1. 장점

   1. 버튼을 한 컴포넌트에서 관리

   2. UX개선:

      1. 유저가 순차적인 작업을 한 곳에서 수행 가능

      2. 순차적으로 버튼 비활성화하여 유저 워크플로우 진행도를 파악하기에 용이함

2. 적용화면

   1. 노드 연결 직후

      1. 

   2. convert

      1. 

   3. train 시작 이후

      1. 

배운 점 - 재사용성

컴포넌트의 재사용성이 극대화되는 것도 체감하였습니다. 학습 결과만 모아서 보여주는 Detail Page를 개발할 때 View로 사용되었던 TrainResultTab이 props도 쓸 필요 없이 그대로 import만 하면 사용할 수 있게 되어 재사용이 매우 간편하였습니다.