React → Rhymix Blade 컨버팅 후기

  잘 된 점                                                                                          

  정적 UI 변환은 생각보다 매끄러웠다. React의 JSX와 Tailwind 클래스는 Blade로 거의 1:1 옮길 수 있었다.

   className → class, onClick → @click(Alpine.js) 정도의 치환이면 됐고, 디자인 토큰(#FF6B35, #111111

  등)은 그대로 가져왔다.                                                                            

  Alpine.js가 React의 빈자리를 잘 채웠다. 탭, 아코디언, 위저드 스텝, 모달 같은 클라이언트 인터랙션은  

  Alpine.js의 x-data, x-show, @click으로 충분히 구현 가능했다. React의 useState가 Alpine의 x-data로,  

  조건부 렌더링이 x-show로 자연스럽게 매핑됐다.                                                       

  34개 페이지 + 7개 섹션을 만들 수 있었다. 피그마 메이크가 만든 React 코드가 컴포넌트 구조를 잘       

  잡아놔서, 어떤 페이지가 필요한지 파악하기 쉬웠다.                                                   

  ---                                                                                                 

  어려웠던 점                                                                                         

  1. Blade v2의 파싱 지뢰밭                                                                           

  이게 가장 큰 고통이었다. 정리하면:                                                                  

  ┌──────────────────────┬───────────────────────────────────┬───────────────────────────┐            

  │         문제         │               원인                │         발견까지          │            

  ├──────────────────────┼───────────────────────────────────┼───────────────────────────┤            

  │ ${variable} 충돌     │ JS 템플릿 리터럴을 Blade가 가로챔 │ 초반에 발견               │            

  ├──────────────────────┼───────────────────────────────────┼───────────────────────────┤            

  │ function 키워드 금지 │ @php 안에서 클로저 사용 불가      │ board_write에서 터짐      │            

  ├──────────────────────┼───────────────────────────────────┼───────────────────────────┤

  │ {top: 0} 파싱        │ JS 객체를 v1 변수로 해석          │ subscribe에서 Fatal error │

  ├──────────────────────┼───────────────────────────────────┼───────────────────────────┤

  │ 주석 안 {!! !!}      │ 주석도 Blade가 파싱               │ PHP 코드가 텍스트로 노출  │

  └──────────────────────┴───────────────────────────────────┴───────────────────────────┘

  React에서는 절대 만날 일 없는 종류의 버그들이다. Blade가 PHP 위에 올라간 템플릿 엔진이다 보니, PHP

  문법과 Blade 문법과 JavaScript 문법이 세 겹으로 충돌하는 지점이 예상보다 많았다.

  2. SPA → MPA 패러다임 차이

  React는 라우터 하나에 49개 컴포넌트를 매핑하면 끝이지만, Rhymix는 mid + act + document_srl 조합으로

  라우팅된다. 이걸 layout.html의 file_exists() 패턴으로 브릿지하는 게 처음엔 어색했다. 결국 라우팅

  로직 자체를 새로 설계해야 했다.

  3. 에디터/폼 제출 같은 CMS 내장 기능 연동

  React 버전은 UI만 있으면 됐는데, Rhymix에서는 실제로 procBoardInsertDocument가 동작해야 했다. hidden

   content 필드, procFilter, $oDocument->getEditor() 같은 Rhymix 내부 규약을 알아야 했고, eb_empty

  스킨이 아무것도 출력 안 하는 구조라 에디터가 빠지는 문제도 있었다. 이건 React 코드에는 전혀 없는

  영역이다.

  4. 데이터 레이어의 근본적 차이

  React 버전은 모든 데이터가 하드코딩이거나 mock이다. Rhymix에서는 실제 DB에서 가져와야 하는데,

  ElMainBoard 헬퍼를 만들고, extra_vars가 배열인지 stdClass인지 체크하고, bulk_post 도구까지 만들어야

  했다. 피그마 메이크는 "보이는 것"만 만들어주고, "동작하는 것"은 전부 새로 해야 한다.

  ---

  결론

  피그마 메이크의 React 출력물은 "디자인 스펙 문서"로서 가치가 있다. 어떤 페이지가 필요하고, 각

  페이지에 어떤 섹션이 있고, Tailwind 클래스가 어떤 건지 명확하게 보여준다. 코드를 직접 가져다 쓸 수

   없지만, 디자인 의도를 파악하는 데는 피그마 원본보다 오히려 낫다.

  그런데 실제 CMS로 컨버팅하는 작업량은 React 코드량의 1.5~2배는 된다. UI 변환(40%) + 라우팅/데이터

  연동(30%) + CMS 규약 맞추기(20%) + 디버깅(10%) 정도 체감이었다.

  만약 다시 한다면, eb_empty 대신 최소한의 write_form/view 출력을 하는 스킨을 쓰는 게 에디터 연동

  등에서 훨씬 편했을 것 같다.