아이디어에 대한 간략한 소개:
객체에 ajax를 적용한 다음 자식에서 부모로객체를 생성하고, 스타일을 설정하고, 레벨을 추가합니다.
그러면 코드는 다음과 같습니다:
그렇습니다. . . 최적화하는 방법?
ES6의 프론트엔드 지원이 이상적이지 않아 문자열 템플릿을 사용할 수 없고, 프레임워크를 강제로 추가해야 한다면 어떻게 해야 하나요?
문자열 연결 후 직접 innerHTML을 사용하는 것과 비교할 때 이런 방식으로 작성하는 경우의 단점은 무엇입니까?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
먼저 JS 인간이 DOM을 유지하기 위해 사용하는 [절차적 프로그래밍]은 유지 관리 측면에서 템플릿 스타일 [선언적 프로그래밍]보다 열등합니다.
<p>xxx</p>和一大坨document.createElement('p')...라는 간단한 라인을 고려하면 유지 관리 가능성에 차이가 있습니다.그렇다면 ES6이나 다양한 프레임워크의 설탕 구문 없이 문자열 템플릿과 유사한 방법을 사용하여 데이터를 HTML에 바인딩하는 방법은 무엇일까요? jQuery 작성자가 한때 권장했던 솔루션은 다음과 같습니다.
먼저 HTML로 외부에서 음란한
으아악<script>标签装模板，注意这个模板本身对 JS 并没有任何依赖，也可以把模板放在<body>을 만들 수 있습니다.데이터를 렌더링할 때 템플릿에서 HTML 텍스트를 직접 꺼내고 JS를 사용하여 정기적으로 교체합니다.
으아악내 블로그를 참조하세요:
http://ewind.us/2016/js-rende...
물론 innerHTML을 완전히 재설정하면 성능 위험이 있습니다. 하지만 데이터가 완전히 업데이트되면 코드가 네이티브 JS로 작성되더라도 최종 DOM 작업 횟수는 실제로 innerHTML을 직접 재설정하는 것과 같습니다. 현재 몇 가지 아이디어가 있습니다:
React는 이런 문제를 해결하기 위해 탄생했습니다. React를 innerHTML로 생각하고 마음대로 재설정하면 React가 필요에 따라 DOM을 비교하고 업데이트하는 데 도움이 될 것입니다.
Vue는 의존성 수집을 통해 변경된 DOM의 위치를 직접 찾아내고 필요에 따라 업데이트할 수 있습니다. diff도 사용하지 않고, 얼마나 높은지도 모르겠습니다.
diff 알고리즘(예: 마지막에만 삽입)과 비즈니스 요구 사항에 맞는 DOM 작업을 유지합니다. 어쩌면 새로운 휠 탄생의 서막일지도 모르겠습니다(
구조가 너무 복잡하고, 우아하지 않으며, 순전히 물리적인 저항이 있으며, 디버깅은 단순히 악몽일 뿐입니다. 앞으로 코드 유지 관리가 너무 많아질 것입니다!
JS 파일을 소개하는 artTemplate과 같은 프런트 엔드 JS 템플릿 엔진을 사용하는 것이 좋습니다.
가장 간단한 장점: innerHTML보다 빠릅니다.
이런 구조물 수백 개를 한 번에 추가하면 확연한 속도 차이를 경험할 수 있습니다