단일 페이지 애플리케이션 세트는 서로 다른 파트너와 연결되어야 하므로 UI를 조정해야 하고 때로는 일부 상호 작용을 변경해야 하지만 전체 프로세스는 기본적으로 동일합니다.
현재 우리는 Vue를 사용하여 프로젝트를 재구성하고 공개 비즈니스 로직을 비즈니스 레이어로 분리할 계획입니다. 그러나 페이지 수준 구성 요소를 작성할 때 로그인 페이지와 같이 여전히 재사용 가능한 코드가 가장 많다는 것을 발견했습니다.
으아아아모든 버전에 존재합니다. 기본적으로 일련의 뷰모델을 사용하여 이 비즈니스 프로세스를 설명할 수 있습니다. 반복되는 코드 중 이 부분은 재사용이 가능하다고 생각합니다.
새 버전마다 대부분의 변경 사항은 스타일과 약간의 상호 작용입니다(상호 작용도 많지만 특정 비즈니스 논리 프로세스는 변경되지 않습니다).
그러나 일반적으로 UI 구성 요소가 먼저 있어야 하고 그 다음에는 비즈니스 구성 요소가 있어야 합니다. 여기서 디자인은 비즈니스 구성 요소가 먼저 있고 그 다음이 UI 구성 요소입니다.
아이디어가 너무 난잡하네요. 의견 좀 부탁드립니다. 감사합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
먼저 [컴포넌트]와 모듈의 개념을 구분해주세요. 구성 요소는 UI 상호 작용을 표현하는 데만 사용되며 프런트엔드 및 백엔드 요청과 같은 비즈니스 로직을 포함해서는 안 됩니다.
구체적으로 말하자면, Sass 기반 사이트 개발에서는 이러한 유형의 [기능 구성 가능] 요구 사항을 처리해야 하는 경우가 많습니다.
백엔드는 [기능 구성] 인터페이스를 열고, 페이지가 로드되면 프런트엔드는 [현재 페이지 구성 매개변수] 정보를 얻습니다
프런트엔드는 각 비즈니스 로직을 독립적인 JS 모듈로 캡슐화하고 내보내기 모듈 기능을 통해 Vue의 UI 레이어에 비즈니스 기능을 제공합니다.
프런트 엔드 UI 레이어는 기능 구성에 따라 다양한 모듈 기능을 호출합니다.
간단히 말하면 개발 모델은 Vue 단일 페이지 애플리케이션과 일치합니다. 기능 구성을 기반으로 UI 로직을 정의하는 JS 모듈을 추가하고 캡슐화하면 됩니다.
동적 테마 전환 기능은 구성 인터페이스를 통해서도 구현할 수 있습니다. 예를 들어 구성 인터페이스의 스타일 필드는 현재 비즈니스 당사자의 테마를 식별하는 className 접두사를 저장한 다음 해당 CSS를 사용하여 스타일 접두사를 현재 페이지에 바인딩하면 테마 전환을 쉽게 구현할 수 있습니다.
P.S. 프로젝트 초반에는 믹스인을 사용하지 마세요. 믹스인은 비즈니스 로직을 찾고 디버깅하기 어렵게 만들 수 있습니다(믹스인을 혼합한 후 알 수 없는 위치에서 가져온 함수 및 변수를 참조할 수 있음). 올바른 접근 방식은 요청 시 비즈니스 모듈을 가져오는 것입니다.:classUI와 기능적 구성 요소(예: 네트워크 요청, 로컬 저장소)를 분리하고 기능적 구성 요소는 기본적으로 자유롭게 결합할 수 있습니다.