programing

대용량 데이터에 대한 Vue 2 메모리 사용 처리 방법(약 50,000개의 개체)

prostudy 2022. 3. 26. 16:44
반응형

대용량 데이터에 대한 Vue 2 메모리 사용 처리 방법(약 50,000개의 개체)

나는 Vue 2에서 세미 복합 객체의 대규모 컬렉션을 위한 테이블 뷰를 구현하려고 한다. 기본적으로 DB에서 JS 캐시로 50,000에서 100,000 행 사이의 행을 수집한 다음, 동적으로 분석하여 실시간 필터(텍스트 검색)로 테이블 뷰를 구축한다.테이블 내의 각 행은 토글 가능하므로, 행을 클릭하면 해당 필드/셀에 대해 엑셀과 같은 편집이 가능한 편집 모드로 변경된다.

각 물체에는 약 100-150개의 필드/속성이 있지만 테이블 내에서 주어진 순간에는 일정량의 필드/속성만 표시된다(테이블 열은 실시간으로 토글할 수 있음).대규모 데이터셋의 경우 DB가 약 10~100mb의 JSON 데이터를 추진하고 있는 것으로 보이며, 이 사용 사례에서는 이를 수용할 수 있다.성능을 렌더링하는 것은 문제가 되지 않는다. 필터는 충분히 빨리 작동하며 제한된 양의 결과만 DOM에 렌더링된다.

모든 것이 이미 작동하고 필터, 필터에 대해 100행까지 나열하고 (+ "100여 개 더 보여"-메커니즘 등) 하지만 약 8000개의 객체를 배열로 로드했을 때 메모리 한계에 부딪쳤다.이것은 2기가바이트의 RAM을 예약한 것으로 보이는데, 크롬이 JS 코드 실행을 모두 중지한 후(이상하게도 나는 어떤 종류의 경고/오류도 받지 않는다)

행에 대한 메모리 사용량을 벤치마킹했는데, 약 1000개의 행은 300mb의 메모리를 예약하는 것 같다.이것은 아마도 Vue 반응성 관측자들에 의해 유보되었을 것이다.

세 가지 질문:

  1. 특정 어레이 목록 개체(인덱스 등)에 대한 반응도를 전환하여 어레이 자체 내의 개체들이 돌연변이가 되기 위해 특별히 호출되지 않는 한(즉, 사용자가 행을 클릭할 때 편집 모드를 활성화)할 수 있도록 하는 방법이 있는가?
  2. 반응성이 메모리 사용량에 병목 현상을 일으키는 것처럼 보이므로 Vue에 대한 대규모 데이터셋 처리를 어떻게 구현하시겠습니까?여기서 찾고 있는 솔루션이 아니므로 "백엔드 내에서 결과 제한"을 제안하지 마십시오(소규모 초기 데이터 집합을 가져오는 방법과 실시간 필터링을 위한 두 부분 필터링을 만들어야 할 수도 있음).기본적으로 나는 Vue와 데이터 아키텍처를 다시 생각함으로써 "기억의 끝"의 경계를 8 000 -> 80 000에서 밀어내려고 한다.Vue의 데이터 변수 내에 데이터셋을 저장해야 하는 유일한 문제는 사후 대응적 데이터인가?
  3. 내가 가진 한 가지 아이디어는 "항목" -데이터세트를 관찰할 수 없는/비활성 개체로 바꾸는 것이다.동결 또는 유사한 접근방식을 적용하고 두 개의 데이터셋을 렌더링할 수 있는 테이블이 있다. 하나는 비필수 데이터셋이고 다른 하나는 현재 편집 모드에 있는 데이터셋("편집 가능"으로 푸시됨)행 클릭 시 항목" 데이터 집합...여기에서 제안할 수 있는 사항(단순히 한 어레이 내에서 모든 작업을 처리할 수 있도록 하는 방법)

앵글 1에도 비슷한 어플리케이션을 해 봤는데, 50,000줄도 꽤 잘 처리했으니까, Vue 2에서도 할 수 있을 거라고 확신해...반응성을 다루는 방법을 찾는 문제일 뿐이야

20.4.2021 편집 - 2년 후, 2년 후 더 현명함

이 질문/답변은 많은 주목을 받았으며 오랜 시간이 지난 후에도 여전히 유효하기 때문에 나는 몇 가지 조언을 하고 싶었다.아래에 있는 대부분의 세부사항들은 여전히 유효하다.그러나 필자는 필터링된 결과 및 복잡한 객체를 다룰 때 Lodash(또는 네이티브 JS 기능의 현대 버전)와 함께 VueX를 사용하는 방향으로 방향을 잡고자 한다.

백엔드의 스트레스를 완화하기 위해 다음과 같은 작업을 단순하게 수행할 수 있다.관련 모델이 없는 일반 객체를 가져오십시오.즉, 기본 결과에는 관련 개체에 대한 ID 키만 있다는 것을 의미한다.Axios 또는 유사한 라이브러리를 사용하여 별도의 AJAX 요청("고객", "프로젝트", "로케이션")이 있는 관련 데이터를 모두 가져오고 VueX를 사용하여 해당 데이터를 자체 목록 속성에 저장하십시오.각 게이터 생성(예:

projectsById: state => {
    return _.keyBy(state.projects, "id")
},

이 방법으로 필요할 때 레이블 및/또는 전체 객체를 가져오는 데 관련 모델을 사용할 수 있으며 백엔드가 관련 데이터를 두 번 이상 가져올 필요가 없다.주와 게이터도 마이크로 컴포넌트 내에서 이용할 수 있을 것이다.

기본적으로:대규모 데이터셋을 처리할 때 전체 모델 트리를 가져오지 마십시오(C# EF 또는 PHP Laravel이 해당 모델에게 도구를 제공함에도 불구하고).원자성 접근법 사용:20개의 다른 목록("Axios.all([...])"을 가져와서 각각 컨트롤러 끝점이 있고 결과를 VueX 스토어에 캐싱하십시오.그리고 즐겁게 지내세요;)

12.03.2019 편집 - 이 답변의 끝 부분에 추가 팁

이 질문을 한 지 오래되어 드디어 프로젝트의 이 부분을 최적화하게 되었다.이런 퍼포먼스나 기억력 문제가 있는 사람에게는 몇 가지 조언을 해주고 싶다.

Vue 설명서에서는 실제로 설명하지 않았지만 앤드레이가 지적한 대로 구성 요소 개체를 사용자 지정 개체 및 개체 목록을 위한 데이터 스토리지로 사용할 수 있다.결국, 그것은 평범한 자바스크립트-객체일 뿐이다.

최적화 후 목록 구성 요소 설정은 다음과 같다.

module.exports = {
    items: [],
    mixins: [sharedUtils],
    data: function() {
        return {
            columns: {
                all: []
    etc... Lot's of data & methods

아이템 배열은 수천 개의 복잡한 물체(데이터 80mb, 압축 6mb)로 채워져 있는데, 이 물체는 내가 비반응으로 처리하고 있다.이것은 내가 생각했던 것보다 덜 문제가 되었다 -- 사용자가 일부 필터 버튼 및/또는 입력된 문자열 필터링을 클릭할 때마다 이 어레이의 필터링을 트리거하는 구조를 이미 사용하고 있었다.기본적으로 이 "프로세스필터"-메소드는 응답하지 않는 항목 배열과 데이터 컨텍스트에 저장된 filterItem을 반환한다.따라서 변이될 때 자동으로 반응하게 된다.

<tr v-for="item in filteredItems" 

이렇게 하면 필터링된 항목 내의 모든 항목이 반응성을 유지하지만 필터링된 항목도 반응성을 잃게 되므로 메모리 뭉치가 절약된다.무려 1200mb가 400mb로 쪼그라들었는데, 그게 바로 내가 찾던 것이었다.똑똑해!

해결해야 할 몇 가지 문제가 있다.항목이 데이터 컨텍스트에 존재하지 않기 때문에 템플릿 내에서 직접 사용할 수 없다.이것은 글을 쓰는 대신...

<div v-if="items.length > 0 && everythingElseIsReady">

…데이터 소품을 분리하기 위해 아이템 배열의 길이를 저장해야 했다.이것은 계산된 값으로 고정될 수도 있었지만, 나는 그 속성들을 그대로 유지하고 싶다.

메인 데이터 어레이의 반응성을 포기하는 것은 결국 그렇게 나쁜 일은 아니다 - 가장 중요한 부분은 해당 베이스 어레이 내의 항목에 대해 직접 이루어지는 수정이 UI 및/또는 서브 컴포넌트(douh)에 대한 변경을 유발하지 않는다는 것을 이해하는 것이다.백엔드에서 모든 결과를 저장하는 "숨겨진 데이터 컨테이너"를 가지고 있고 대형 컨테이너의 더 작은(필터링된) 프리젠테이션 어레이를 가지고 있을 정도로 코드를 분리하는 한 이것은 그렇게 문제가 되지 않을 것이다.좋은 REST 아키텍처를 사용함으로써 비활성 데이터 스토리지 내의 항목을 저장한 후 최신 개정판으로 업데이트되었는지 확인하는 것이 기억나는 한, 이미 비활성 데이터 스토리지로 전환하기에 적합해야 한다.

게다가 나는 성능 면에서 얼마나 많은 마이크로 컴포넌트가 수백 개의 행에 반대하는지 별로 중요하지 않다는 것에 당황했다.렌더는 분명히 히트를 치지만, 내가 (입력 셀의 수천 가지 예를 가지고 있기 때문에) 큰 소품들을 수천 번 통과한다고 해도, 그것은 기억에 맞지 않는 것 같았다.이런 종류의 물건들 중 하나는 글로벌 번역-키/값-페어 오브젝트인데, 20,000줄 이상의 번역된 문자열을 가지고 있다...하지만 그건 여전히 중요하지 않았어이는 Javascript가 객체 참조를 사용하고 Vue Core가 적절하게 코드화된 것처럼 보이므로 이러한 구성 객체를 소품으로 사용하는 한 단순히 수천 개의 객체에서 동일한 데이터 집합으로 언급하는 것이다.

마지막으로, 기억력 제한에 부딪힐 염려 없이 복잡한 CRUD 물체에 열광하기 시작하자!

안드레이 포포프가 올바른 방향으로 밀고 나가게 해줘서 정말 고마워!

팁(12.03.19)

오랜 시간이 지났고 나는 크고 복잡한 데이터셋으로 UI를 계속 구축해 왔기 때문에 나는 몇 가지 짧은 아이디어와 팁을 빼기로 결정했다.

  1. 마스터 레코드(예: 개인 또는 제품) 대 관련 레코드(하위 개체/관계 개체)를 관리하는 방법을 고려하십시오.서로 다른 마스터 레코드에 대해 동일한 하위 객체를 여러 번 나타낼 수 있으므로 하위 구성요소에 대해 주입되는 데이터 양을 제한하십시오.문제는 이 물체들이 실제로 참조 물체가 아닐 가능성이 있다는 것이다!

도시-개체가 포함된 개인-개체가 있는 상황을 고려하십시오.여러 사람이 동일한 도시에 거주하지만, 백엔드에서 JSON-데이터를 가져올 때 실제로 하나의 도시와 동일한 도시(사람들 간에 공유/참조된 도시 객체) 또는 유사한 개체의 다중 표현(데이터가 정확히 동일하지만 후드 아래 각각 개별 인스턴스(instance)/유일한 o)인지 확인하십시오.bject. 50,000명의 인원을 보유하고 있다고 가정해 봅시다. 각 인원은 동일한 하위 개체/재산권 "도시"를 포함하고 있다고 합시다: {ID: 4, 이름: "메가타운"}, 단지 한 개 대신 개별 도시 인스턴스 50,000개를 가져왔는가?person1.city ===person2.city인가, 아니면 그저 똑같이 생겼을 뿐 여전히 두 개의 다른 물체인가?

공유된 도시-객체 또는 유사한 하위 객체의 수십 개의 인스턴스를 사용하는지 확실하지 않은 경우, 간단히 사용자 목록-구성 요소 내에서 참조할 수 있다.사용자에게는 도시 ID가 포함되어 있으므로 별도의 REST-방법(getCities)이 있는 도시의 가져오기 목록과 UI 레벨에서 페어링을 수행하십시오.이렇게 하면 도시 목록이 하나뿐이고, 그 목록에서 도시를 해결하여 직접 투입할 수 있어, 한 도시만 언급할 수 있다.또는 목록에서 도시를 해결하여 개인 구성 요소에게 재산으로 넘길 수도 있다.

또한 하위 객체의 목적이 무엇인지 반드시 고려하십시오.반응성이 필요한가, 아니면 정적인가?기억의 뭉치를 저장하기 위해서, 당신은 단지 "person.city = city"라고 말하면 되는데, 그것은 각각의 모든 개인 구성 요소에 주입될 것이지만, 만약 그것이 반응할 필요가 있다면, 당신은 Vue.set -method...를 사용해야 한다.각 도시가 고유한 인스턴스(instance)가 되어야 하는 경우(각자가 유사한 도시-객체를 가지고 있지만, 숙박시설은 개인당 편집 가능해야 함)에는 참조 객체를 사용하고 있지 않은지 확인해야 한다!따라서 당신은 브라우저 메모리를 소모하는 도시-객체 복제를 가장 많이 할 필요가 있다.

  1. 마이크로 컴포넌트는 읽기 전용 상태와 편집기 상태 모두에 대해 별도의 보기 상태를 포함할 수 있다.이것은 꽤 흔한 일이다.그럼에도 불구하고, 당신은 실제로 매번 그 마이크로 컴포넌트의 인스턴스를 만들고, 따라서 그 컴포넌트를 수천번 초기화한다.

테이블과 테이블 행이 있는 Excel과 같은 스프레드시트가 있는 상황을 생각해 보십시오.각 셀에는 사용자 정의 "my-input" -구성 요소가 포함되어 있으며, 이 구성 요소는 레이아웃에서 "읽기 전용"-속성을 가져온다.UI가 읽기 전용 상태일 경우 my-input-구성 요소 내부에 라벨 부분만 표시되지만, 그렇지 않을 경우 입력 태그가 일부 특수 조건(예: 날짜/시간, 숫자, 텍스트 영역, 선택 태그 등)으로 표시된다.이제 100개의 행에 20개의 열이 있으므로 실제로 2000개의 my-input 구성 요소를 초기화하고 있다고 가정해 봅시다.이제 질문은 -- 어떤 것이 개선될 수 있을까(성과에 따라) 입니다.

내 입력 구성 요소에서 목록 보기로 읽기 전용 레이블을 분리하여 읽기 전용 버전(레이블)을 표시하거나 편집 가능한 my-input-구성 요소를 표시하십시오.이러한 방식으로 v-if 조건을 사용할 수 있으며, 이는 특별히 (읽기 전용 -> 편집 가능 -상태에서 이동하는 행 또는 전체 레이아웃으로 인해) 초기화를 요청하지 않은 한, 2000개의 마이크로 컴포넌트가 초기화되지 않도록 하는 것이다.Vue가 2000개의 구성요소를 작성할 필요가 없는 경우, 브라우저에 미치는 영향이 얼마나 큰지 추측할 수 있을 것이다.

만약 당신이 당신의 페이지가 정말로 느리게 로드되는 것을 마주하고 있다면 그것은 VUE가 아닐지도 모른다.HTML에 렌더링된 HTML 태그의 양을 확인하십시오. HTML은 많은 양의 태그를 가지고 있을 때 성능이 다소 떨어진다.이를 증명하는 가장 간단한 방법 중 하나는 2000개 옵션으로 선택 태그를 100번 반복하거나 20000개 옵션 선택 태그를 하나만 갖는 것이다.불필요한 포장 디브 등을 가진 마이크로 컴포넌트를 많이 가지고 있어서 html 태그의 양을 넘치게 되는 것과 같은 방법...깊이가 적고 태그가 적을수록 브라우저와 CPU에서 렌더링 성능이 요구된다.

예를 들어 HTML 태그 아키텍처에 대해 알아보십시오.예를 들어 Trello -services 대시보드 뷰가 프로그래밍된 방법을 연구할 수 있다.그것은 최소한의 서브-div로 다소 복잡한 서비스를 매우 단순하고 아름답게 표현한다.


메모리 처리를 개선할 수 있는 방법은 여러 가지가 있지만, 가장 중요한 것은 나의 원래 대답에 기술된 바와 같이 눈에 보이는 물체와 "숨겨진" 물체를 분리하는 것과 관련이 있다고 말하고 싶다.두 번째 부분은 차이점 또는 instituted vs referenced objects를 이해하는 것이다.셋째, 객체 간 불필요한 데이터 전달의 양을 제한하는 것이다.

개인적으로 나는 이것을 시도해 본 적이 없지만, 단순히 겉으로 보기에 무한한 양의 데이터를 포장하는 것으로 어떤 양의 데이터도 처리하는 Vue-virtual-scroller 구성요소가 있다.@@ https://github.com/Akryum/vue-virtual-scroller 라는 개념을 확인해보고, 그것이 문제를 해결했는지 나에게 알려줘.

나는 이 지침들이 당신의 요소들을 최적화하기 위한 몇 가지 아이디어를 주길 바란다.절대 희망을 버리지 마라, 항상 개선의 여지가 있다!

내가 읽은 모든 것을 보면, 그 데이터에 대한 반응성이 필요 없다는 것을 알 수 있다. 왜냐하면:

테이블 내의 각 행은 토글 가능하므로, 행을 클릭하면 해당 필드/셀에 대해 엑셀과 같은 편집이 가능한 편집 모드로 변경된다.

이는 행을 편집할 수 없고 사용자 상호 작용 없이 데이터를 변경할 수 없다는 것을 의미한다.

각 물체에는 약 100-150개의 필드/속성이 있지만 테이블 내에서 주어진 순간에는 일정량의 필드/속성만 표시된다(테이블 열은 실시간으로 토글할 수 있음).

필드는 활성 상태로 유지하되 표시하지는 않는다.


그리고 이제 너의 질문은

특정 어레이 목록 개체(인덱스 등)에 대한 반응도를 전환하여 어레이 자체 내의 개체들이 돌연변이가 되기 위해 특별히 호출되지 않는 한(즉, 사용자가 행을 클릭할 때 편집 모드를 활성화)할 수 있도록 하는 방법이 있는가?

한 번에 편집할 수 있는 단일 항목이 있다면 왜 모든 항목을 반응적으로 유지하시겠습니까?단일 변수를 사용하여 이러한 변화를 쉽게 들을 수 있다.

반응성이 메모리 사용량에 병목 현상을 일으키는 것처럼 보이므로 Vue에 대한 대규모 데이터셋 처리를 어떻게 구현하시겠습니까?

그것은 구현에 관한 모든 것이다 - 당신은 반응하기 위해 엄청난 양의 아이템이 필요한 상황에 놓이지 않는다.품목이 많을수록 반응성을 이용하려면 사건이 더 많이 일어나야 한다.50,000개의 항목이 있고 사용자가 수동으로 데이터를 수정하는 것과 같은 몇 가지 이벤트만 있다면, Vue가 모든 데이터를 처리하도록 놔두지 않고 해당 이벤트를 쉽게 청취하고 반응성을 수동으로 만들 수 있다.Vuex를 확인하면 삶을 좀 더 편하게 할 수 있다 :)

내가 가진 한 가지 아이디어는 "항목" -데이터세트를 관찰할 수 없는/비활성 개체로 바꾸는 것이다.동결 또는 유사한 접근방식을 적용하고 두 개의 데이터셋을 렌더링할 수 있는 테이블이 있다. 하나는 비필수 데이터셋이고 다른 하나는 현재 편집 모드에 있는 데이터셋("편집 가능"으로 푸시됨)행 클릭 시 항목" 데이터 집합)

이것은 올바른 방향으로 가고 있지만 두 개의 어레이를 지원할 필요는 없다.다음과 같은 것을 사용한다고 상상해 보십시오.

data: function() {
    return {
        editingItem: {}
        // when editing is enabled bind the input fields to this item
    }
},
created: function() {
    this.items = [] // your items, can be used in markdown in the loop, but won't be reactive!
},
watch: {
    editingItem: function(data) {
        // this method will be called whenever user edits the input fields
        // here you can do whatever you want
        // like get item's id, find it in the array and update it's properties
        // something like manual reactivity ;)
    }
}
  • 나는 이 문제를 정확히 짚고 넘어가야 했다. 5만개의 아이템을 적어도 가변 높이로 생각해야 했고, 그것에 대한 해결책을 찾을 수 없었다.
  • 일반적인 해결책은 가상 스크롤을 제작/사용하는 것이다.
  • DOM에는 몇 가지 항목만 보관하고 나머지 항목은 DOM에서 편집한다.그러나 위/아래 스크롤 여부에 따라 표시되는 항목이 계속 변경됨
  • 내가 찾은 기존 라이브러리는 vue-virtual-scrollervue-virtual-scroll-list와 같은 높이를 하드코드로 지정하지 않는 한 동적 높이를 처리하지 않음
  • vue-flash-cluster를 통해 동적으로 높이를 계산할 수 있지만 5만 개 항목에서 형편없이 뒤처짐
  • 그래서 5만개 이상의 아이템에서 SUPER SLASE를 스크롤하고, 심지어 100,000개 아이템으로 테스트도 하고 꽤 잘 작동하는 나만의 솔루션을 고안해 냈다.
  • 동적 행 높이에 대한 구현 아이디어는 다음과 같다.
  • 배열의 각 항목에 대한 높이 목록을 유지 관리해야 함

  • 상단 스크롤 위치에 따라 변환 변환Y를 수직으로 적용하여 사용자에게 항상 표시되는 몇 가지 항목을 상쇄한다.

여기에 이미지 설명을 입력하십시오.

  • 나는 네가 무슨 일이 일어나고 있는지 쉽게 알 수 있도록 솔루션에 충분한 코멘트를 추가했다.

HTML

<script type="text/x-template" id="virtual-list">
   <div id="root" ref="root">
      <div id="viewport" ref="viewport" :style="viewportStyle">
        <div id="spacer" ref="spacer" :style="spacerStyle">
         <div v-for="i in visibleItems" :key="i.id" class="list-item" :ref="i.id" :data-index="i.index" @click="select(i.index)"  :class="i.index === selectedIndex ? 'selected': ''">
           <div>{{ i.index + ' ' + i.value }}</div>
   </div>
   </div>
   </div>
   </div>
</script>
<div id="app">
   <h1 class="title">
      Vue.js Virtual + Infinite Scroll + Dynamic Row Heights + Arrow Key Navigation + No Libraries
   </h1>
   <p class="subtitle">
      No hardcoding of heights necessary for each row. Set emitEnabled to false
      for max performance. Tested with <span id="large_num">50000</span> items...
   </p>
   <div id="list_detail">
      <div id="list">
         <virtual-list></virtual-list>
      </div>
      <div id="detail">
         <table>
            <tbody>
               <tr>
                  <th class="caption">Root Container Height</th>
                  <td>{{store['root-height']}} px</td>
               </tr>
               <tr>
                  <th class="caption">Viewport Height</th>
                  <td>{{store['viewport-height']}} px</td>
               </tr>
               <tr>
                  <th class="caption">Smallest Row Height</th>
                  <td>{{store['smallest-height']}} px</td>
               </tr>
               <tr>
                  <th class="caption">Largest Row Height</th>
                  <td>{{store['largest-height']}} px</td>
               </tr>
               <tr>
                  <th class="caption">Scroll Top</th>
                  <td>{{store['scroll-top']}} px</td>
               </tr>
               <tr>
                  <th class="caption">Page Index</th>
                  <td>{{store['page-start-index']}}</td>
               </tr>
               <tr>
                  <th class="caption">Start Index</th>
                  <td>{{store['start-index']}}</td>
               </tr>
               <tr>
                  <th class="caption">End Index</th>
                  <td>{{store['end-index']}}</td>
               </tr>
               <tr>
                  <th class="caption">Translate Y</th>
                  <td>{{store['translate-y']}} px</td>
               </tr>
            </tbody>
         </table>
         <p><b>Visible Item Indices on DOM</b> {{store['visible-items']}}</p>
         <p><b>Total Height Till Current Page</b> {{store['page-positions']}}</p>
         <p>
            <b>Row's Vertical Displacement From Viewport Top</b>
            {{store['row-positions']}}
         </p>
         <p><b>Heights</b> {{store['heights']}}</p>
      </div>
   </div>
</div>

CSS

@import url('https://fonts.googleapis.com/css?family=Open+Sans&display=swap');

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}


/**
Apply Scroll Bar Styles

https://css-tricks.com/the-current-state-of-styling-scrollbars/
*/
html {
  --scrollbarBG: #181C25;
  --thumbBG: orange;
}
body::-webkit-scrollbar {
  width: 11px;
}
body {
  scrollbar-width: thin;
  scrollbar-color: var(--thumbBG) var(--scrollbarBG);
}
body::-webkit-scrollbar-track {
  background: var(--scrollbarBG);
}
body::-webkit-scrollbar-thumb {
  background-color: var(--thumbBG) ;
  border-radius: 6px;
  border: 3px solid var(--scrollbarBG);
}


html {
  height: 100%;
}

body {
  min-height: 100%;
  height: 100%;
  padding: 2rem;
  color: #AAA;
  background: #181C25;
  font-family: 'Open Sans', sans-serif;
  font-size: 0.9rem;
  line-height: 1.75;
}

#app {
  height: 100%;
  display: flex;
  flex-direction: column;
}

#list_detail {
  display: flex;
  height: 70%;
}

#list {
  flex: 2;
  height: 100%;
}

#detail {
  flex: 1;
  padding: 1rem;
  overflow: auto;
  height: 100%;
}

#root {
  height: 100%;
  overflow: auto;
}

.list-item {
  padding: 0.75rem 0.25rem;
  border-bottom: 1px solid rgba(255, 255, 0, 0.4);
}

.title {
  color: white;
  text-align: center;
}

.subtitle {
  color: orange;
  text-align: center;
}

table {
  width: 100%;
  table-layout: fixed;
  text-align: center;
}

th.caption {
  text-align: left;
  color: #00BEF4;
  font-weight: 100;
  padding: 0.5rem 0;
}

td {
  text-align: left;
}

b{
  font-weight: 100;
  color: #00BEF4;
}

#large_num {
  color: red;
}

.selected {
  background: midnightblue;
}

Vue.js

나는 SO에서 3만자로 제한되고 있다. 따라서 여기에 CodePen의 전체 코드가 있다.

제한 사항

  • 현재 작업 중인 화면 크기 조정과 함께 잘 재생되지 않음

특징들

  • 50000개 이상의 항목을 쉽게 스크롤할 수 있음
  • 화살표 네비게이션이 네이티브 목록처럼 지원됨

  • 궁금한 점이 있으면 댓글로 알려줘.

많은 구성품 목록을 만들기 위해 나는 방금 https://github.com/RadKod/v-lazy-component이 그것을 정말 좋아한다는 것을 발견했다.컴포넌트를 렌더링하거나 렌더링하지 않을 때 교차로 API를 사용한다.눈에 보이지 않는 게으르게 적재된 구성부품을 제거하고 눈에 보이는 구성부품을 불필요한 합병증 없이 매우 매끄럽게 적재한다.

참조URL: https://stackoverflow.com/questions/48515997/how-to-handle-vue-2-memory-usage-for-large-data-50-000-objects

반응형