프런트엔드 템플릿 엔진 문제에 대한 자세한 설명

프론트 엔드 템플릿 엔진은 개발 중에 투명해야 합니다

투명성은 개발 환경을 설정한 후 코드를 작성하고 브라우저를 새로 고쳐 추가 명령을 실행하지 않고도 최신 효과를 볼 수 있다는 것을 의미합니다. 또는 대기 프로세스.

따라서 컴파일 프로세스에 의존하는 모든 템플릿 엔진은 프런트엔드 사용에 적합하지 않습니다. 컴파일은 템플릿 엔진의 기능일 뿐이며 사용을 위한 전제 조건은 아닙니다.

더 엄밀히 말하면 FileWatch 및 기타 수단을 사용하세요. 파일 변경 사항을 감지하고 자동으로 컴파일합니다. 또한 추가 대기 시간이 발생하므로 고려 대상 범위에 포함되지 않습니다. 이로부터 프런트 엔드 템플릿 엔진에는 구문 분석 및 사용이 가능해야 한다는 것을 추론할 수 있습니다. 순수한 프런트엔드 환경.

프런트엔드 템플릿 엔진은 런타임 디버깅 기능이 좋아야 합니다

사용자 행동의 불확실성, 실행 환경의 불확실성, 다양한 타사 스크립트의 영향 등으로 인해 프런트엔드가 어렵습니다. -end는 완전한 오류 처리 및 추적을 달성하기 위해 프런트 엔드가 온라인에서 직접 문제를 해결해야 한다는 사실로 이어집니다그리고 문제가 템플릿 엔진 수준에서 발생하면 템플릿 엔진은 우수한 디버깅 기능을 제공해야 합니다

일반적으로 말하자면, 컴파일 후 생성된 함수의 디버깅 능력은 수동으로 작성된 원본 템플릿 조각보다 약합니다. 자동으로 생성된 함수는 기본적으로 읽을 수 없고 중단점 추적이 가능하지 않기 때문입니다

따라서 이 시점에서 프런트엔드용 템플릿 엔진은 특정 상황에서는 "컴파일된 함수를 실행하여 HTML을 얻습니다" 모드가 "원본 템플릿을 구문 분석한 후 함수를 실행하여 HTML을 얻습니다"로 다시 변경됩니다. 즉, 두 모드 사이의 전환을 지원해야 합니다

또는. 더 좋은 점은 강력한 프런트엔드 템플릿 엔진이 컴파일된다는 점입니다. 생성된 함수는 소스 맵이나 기타 사용자 정의된 수단을 사용하여 원본 템플릿 조각에 직접 다시 매핑될 수 있습니다. 그러나 현재 프런트엔드 템플릿 엔진은 이 기능을 구현해야 합니다. 파일 병합에 적합 HTTP/ 2가 널리 사용되기 전에는 파일 병합이 여전히 프런트엔드 성능 최적화에 중요한 수단이었습니다. 파일의 일부인 템플릿은 여전히 ​​컴파일 기능을 제공하는 템플릿 엔진에서 병합되어야 합니다. 컴파일을 사용하여 템플릿을 JavaScript 소스 코드로 변환한 다음 JavaScript 기반 파일을 병합할 수 있습니다

그러나 위에서 언급한 디버깅 기능과 같은 이유로 원본 템플릿 조각을 유지하려면 템플릿 엔진 자체에서 이를 지원해야 합니다. 템플릿 조각을 하나의 파일로 병합

Big 입력 문자열을 템플릿으로 구문 분석하는 것만 지원하는 일부 엔진에는 본질적으로 전체 문자열을 여러 템플릿 조각으로 분할할 수 없으므로 템플릿에서 파일 병합을 지원할 수 없습니다. 조각 수준

파일 병합에 대한 지원을 구현해야 합니다. 가장 좋은 방법은 "조각"을 기반으로 템플릿 구문을 만드는 것입니다.

, 프런트 엔드는 XSS를 제어합니다. 엄격히 필요합니다

프런트 엔드에서 XSS를 방지하는 더 적절한 방법은 "기본 이스케이프" 화이트리스트 전략을 사용하는 것입니다.

이를 기반으로 합리적인 템플릿 엔진은

지원해야 합니다 기본 이스케이프, 즉 모든 데이터 출력은 기본적으로 이스케이프 논리에 의해 처리되며 키 기호는 해당 HTML 엔터티 기호로 변환되어 루트에서 XSS의 침입 경로를 제거합니다. 물론 모든 콘텐츠를 이스케이프해야 하는 것은 아닙니다. 사용자는 서식 있는 텍스트를 입력해야 하므로 이스케이프되지 않은 출력을 생성하려면 특정 구문을 지원해야 하지만, 이스케이프되지 않은 출력은 특수한 경우이므로 기본적으로 이스케이프 출력되어야 한다는 사실에 항상 주의하세요.

프런트 엔드 템플릿 엔진은 조각 재사용을 지원해야 합니다.

이것은 프런트 엔드 템플릿 엔진의 요구 사항이 아닙니다. 실제로 모든 템플릿 엔진은 Velocity, Smarty와 같은 조각 재사용을 지원해야 합니다. 등 모두 이 기능을 가지고 있습니다. 소위 프래그먼트 재사용에는 다음과 같은 계층적 애플리케이션이 포함되어야 합니다.

프래그먼트는 다른 위치에 도입될 수 있으며 이는 모든 곳에서 사용되는 변수의 효과와 동일합니다

1. 프런트엔드 템플릿 엔진은 데이터 출력 중 처리를 지원해야 합니다

2. 소위 데이터 출력 중 처리란 데이터 조각이 출력 시 추가 변환을 거쳐야 함을 의미합니다. 가장 일반적인 작업은 문자열 다듬기 작업과 마크다운 변환 등과 같은 보다 기술적인 작업입니다.
   데이터를 템플릿 엔진에 전달하기 전에 JavaScript 논리를 통해 데이터 변환을 수행할 수 있다는 것은 사실이지만 이로 인해 추악하고 중복된 코드가 많으며 로직 자체의 재사용성에 부정적인 영향을 미칠 수도 있습니다

일반적으로 템플릿 엔진은 bash의 파이프라인 논리와 유사하게 필터 형태로 데이터에 대한 추가 처리를 수행합니다. 필터 구현 및 등록도 디자인이 다릅니다. 예를 들어 콧수염은 실제로 필터 팩토리를 등록하는 반면 다른 템플릿 엔진은 필터 자체를 직접 등록합니다. 디자인이 다르면 고려 사항도 다릅니다. 누가 나쁜가

하지만 템플릿 엔진이 데이터 출력 처리를 지원한 후에는 코딩 과정에서 새로운 얽힘을 야기하게 됩니다. 즉, 템플릿 엔진의 필터로 어떤 데이터 처리를 구현해야 하는지, 어떤 데이터를 구현해야 하는지에 대한 문제입니다. 템플릿 엔진에 전달되기 전에 우리 자신의 논리를 수행합니다. 이 주제는 긴 토론이므로 현재 주제와 관련이 없다면 그냥 건너뛰십시오

프론트 엔드 템플릿 엔진은 동적 데이터를 지원해야 합니다

개발 과정에서 많은 데이터가 실제로 정적이 아닙니다. 예를 들어 EmberJS는 Computed Property와 같은 개념을 제공하고 Angular도 비슷한 것을 제공하며 Backbone은 Model의 get 메서드를 재정의하여 위장하여 구현할 수 있습니다.

ES5는 언어 수준에서 직접 getter 지원을 제공하지만 우리는 대부분의 시나리오에서 이 언어 기능은 여전히 ​​사용되지 않지만 동적 데이터는 일종의 개체의 get 메서드로 캡슐화됩니다.

템플릿 엔진은 데이터를 HTML 조각으로 변환할 때도 이에 주의해야 합니다. . 한 가지 점은 동적으로 계산된 데이터에 대한 지원이 우수하다는 것입니다.

더 명확하게 말하면 템플릿 엔진은 일반 객체를 입력으로 받아들일 뿐만 아니라 get 메서드를 사용하여 동적 데이터를 받아들이는 데 더 개방적이어야 합니다. 합리적인 논리는 객체에 get 메소드(템플릿 엔진이 이 인터페이스를 결정함)가 있으면 이 메소드를 통해 데이터를 얻는다는 것입니다. 다른 경우에는 입력 객체가 순수 객체(일반 객체)로 간주되고 표준 속성이 다음과 같이 간주됩니다. 획득 논리

프런트 엔드 템플릿 엔진은 비동기 프로세스와 긴밀하게 통합되어야 합니다

가장 일반적인 예는 전 세계적으로 사용되는 상수를 저장하는 AMD 모듈이 있고 템플릿 엔진은 이러한 상수를 사용해야 한다는 것입니다. . 물론 템플릿 엔진을 사용하기 전에 JavaScript가 이 모듈을 비동기적으로 획득한 다음 상수를 템플릿 엔진에 데이터로 전달할 수 있지만 이는 강박 장애에서 비즈니스와 뷰를 결합하는 방법입니다. 이것이 아름다운 디자인이라고 생각하지 마십시오. 따라서 우리는 지금처럼 문자열을 직접 반환하는 대신

템플릿 자체의 출력이 비동기 방식이 되기를 바랍니다.
비동기 방식에 대한 템플릿의 의존성을 분석합니다. 작업 및 전체 문자열의 연결 논리가 여러 비동기로 중단됩니다.
비동기에는 대기가 필요하며 대기는 알 수 없습니다. 성능 관점에서 한 섹션을 완료하려면 스트림 스타일 출력을 고려해야 하며 하나의 섹션을 제공합니까?
가 내장되어 제공됩니다. 여러 유형의 비동기 로직을 ​​수정하거나 Promise를 기반으로 맞춤형 비동기 로직을 ​​지원하여 복잡성과 실용성의 균형을 유지합니다.
지금까지 방법과 방법을 완전히 이해하지 못했습니다. 템플릿을 비동기식으로 결합하는 인터페이스인데 이 주제에 대해서는 제가 할 수 있는 일이 없습니다. 계속해서 심도 있게 논의 중입니다

지금까지 프런트엔드는 개발되었지만, 다음과 같은 다양한 개발 모델이 있습니다.

가장 일반적인 HTML 페이지는 DOMContentLoaded와 같은 이벤트를 사용하여 로직을 추가합니다. 특정 상호 작용에서 페이지를 부분적으로 새로 고칩니다.
단일 페이지 개발에 기존 MVC 모델 사용
데이터를 핵심으로 하는 MVVM 방식 사용, 개발을 위한 데이터 및 뷰 방향 바인딩
Diff to DOM 업데이트의 불변 데이터 개발 기반 데이터 비교(Virtual DOM 도입 포함 가능)
템플릿 엔진이 다양한 모드, 특히 양방향 바인딩을 지원하는 것은 매우 큰 도전입니다. 지금까지 양방향 바인딩을 지원하는 거의 모든 개발 프레임워크에는 전용 템플릿 엔진이 함께 제공됩니다. 이는 양방향 바인딩에 템플릿에 대한 두 가지 주요 요구 사항이 있기 때문입니다. 템플릿은 "데이터 종속성"

• 을 새로 고치지 않고도 템플릿의 어느 부분이 데이터 변경 엔진인지 알 수 있습니다. 그러나 일반 템플릿 엔진은 이 두 가지 기능을 거의 제공하지 않으므로 프론트엔드 개발 모델에 대한 서로 다른 전체 및 내부 지원을 비교할 방법이 없습니다
템플릿 엔진 자체의 구현에서 한 가지 방법은 다른 프레임워크가 합리적으로 처리할 수 있도록 템플릿 구문 분석 후 AST와 유사한 구조를 직접 노출하는 것입니다. 동시에 템플릿 기능의 부분 새로 고침을 제공하지만(앞서 언급한 템플릿 조각과 함께 고려할 수도 있음) 성능상의 이유로 대부분의 템플릿 엔진은 AST와 유사한 구문 구조를 구문 분석하지 않습니다

• 프런트 엔드 템플릿 엔진은 인스턴스 간에 격리가 있어야 합니다

대규모 프런트엔드 프로젝트, 특히 단일 페이지 프로젝트에서는 동시에 존재하는 완전히 알 수 없는 수의 템플릿 조각이 있을 것입니다. 이러한 조각에 이름이 있는 경우(재사용을 고려하여) 이름 충돌이 발생하기 쉽습니다

동일한 수준의 논리(예: 모두가 비즈니스 계층 코드로 작업하거나 모두가 제어 계층 코드로 작업하는 경우)의 경우 일부 개발 규칙을 통해 이름 충돌을 해결할 수 있습니다. 그러나 서로 다른 레이어 사이에서는 캡슐화 요구 사항으로 인해 내부에서만 사용되는 일부 조각의 이름을 외부에서 알 수 없어야 합니다. 이때 불행하게도 이름이 다른 레이어와 충돌하면 이러한 문제가 더욱 복잡해질 수 있습니다. 추적이 쉽지 않고 많은 에너지와 시간 낭비로 이어지는 경우가 많습니다

따라서 좋은 템플릿 엔진은 여러 인스턴스를 가져야 하며, 이러한 예측할 수 없는 충돌을 피하기 위해 서로 다른 인스턴스를 서로 격리해야 합니다

이 주제에서는 단순한 격리만으로는 충분하지 않으며, 서로 다른 레이어 간의 비충돌 외에도 조각 재사용도 필요합니다. 또한 서로 다른 템플릿 인스턴스 간에 일부 고정된 기능을 열어야 합니다. 공유되므로 템플릿 엔진의 각 인스턴스 간의 관계는 종속성의 조합이지만 기본 캡슐화 및 격리가 포함됩니다.

위 내용은 프런트엔드 템플릿 엔진 문제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!