Vue: 비동기 구성 요소 수명 주기 후크 대기

그래서 당신은 원하는

created () {
    return new Promise(resolve => {
        setTimeout(() => {
            console.log('created')
            resolve()
        })
    })
},
mounted () {
    console.log('mounted')
}

표시하다

mounted

?

기능 요청을 생성할 때 실제 사용 사례를 추가하여 요청을 구현할 가치가 있도록 만드십시오.

이것은 이론적으로 멋진 아이디어이지만 달성하려면 아키텍처에 대한 근본적인 재검토/재작성이 필요하며 잠재적으로 수명 주기 후크의 동기적 특성에 의존하는 많은 논리를 깨뜨릴 수 있습니다. 따라서 해당 변경을 정당화하려면 이점이 상당해야 합니다. 그렇지 않으면 이는 곧 발생하지 않을 완전한 업그레이드를 수행할 계획인 경우에만 고려할 수 있습니다.

지금은 종료되지만 보다 구체적인 추론/사용 사례/영향을 자유롭게 후속 조치를 취하십시오.

@posva 이해 -- 죄송합니다. 실제 사용 사례는 UserPage 페이지 경로 매개변수에서 user_id 를 수신한 다음( this.$route.params 를 통해) 데이터베이스에서 실제 사용자 데이터를 가져오는 UserPage 구성 요소가 있는 경우입니다. 다음과 같은 명령을 사용하여 서버에서
this.user = await client.get({type: 'user', id: this.$route.params.id})
여기서 this.user 는 UserPage 구성 요소의 data 부분에 있는 user 필드를 나타냅니다.

이상적으로는 구성 요소가 생성된 후( this.$route.params 를 사용할 수 있도록) 해당 코드 행이 실행되기를 원하지만 구성 요소가 실제로 마운트 되기 전에 템플릿에서 user 안전하게 사용할 수 있습니다

@yyx990803
나는 여기에서 멍청한 사람일 수 있지만 Vue 랜드에서 mounted 등과 같은 수명 주기 후크를 호출하기 전에 await 키워드를 추가하는 것만이 변경되어야 하지 않습니까?

이것은 내가 기다리고 싶은 실제 코드입니다.

  beforeMount: async function() {
       this.user = await client.get({type: 'user', id: this.$route.params.id});
    }

UserPage 구성 요소의 일부가 됩니다.

걱정 마! 나는 그 사용 사례를 상상하고 있었다. 로드 상태를 표시하는 다양한 방법을 열므로 vue-router 문서에 설명된 대로 처리하는 것이 좋습니다. 구성 요소 btw를 렌더링하기 전에 이미 데이터가 있을 때까지 기다릴 수 있습니다.

알겠습니다. 그러나 이제 사용자 페이지의 제거된 버전인 사용자 구성 요소가 있는 경우(예: Facebook에서 사용자 이름 위로 마우스를 가져간 다음 해당 프로필을 "피킹"할 때 나타나는 구성 요소) 라우터 여기에 포함되지 않으며 id 는 구성 요소에 속성으로 전달됩니다.

여기에서 큰 그림을 보면 JavaScript의 함수는 이제 동기식 또는 비동기식일 수 있으며 수명 주기 후크는 함수이고 우리가 이를 함수로 생각하는 방식은 비동기성을 지원해야 합니다(내 사용 사례와 직관적인 "도달"에서 설명한 대로). 내가 여기에서 사용하는 접근 방식에 대해).

많은 방법이 있습니다. 가장 간단한 방법은 null로 시작하는 변수를 사용하고 데이터를 가져오고 설정하여 실제 구성 요소를 토글하는 것입니다(v-if 때문에). 좀 더 이국적인 버전은 구성 요소를 해결하고 <component :is="myDynamicComp"/> 😄를 사용하는 함수입니다.
하지만 문제를 질문으로 도용하지 마세요 😉 이에 대해 포럼이나 디스코드를 사용하세요

아니요, 코드에 대한 도움을 받고 싶지 않습니다! 실제로 귀하의 제안과 매우 유사한 해결 방법을 이미 구현했습니다. 내가 말하려는 것은 JS 비동기 기능을 사용하는 것이 훨씬 더 직관적이라는 것입니다.

내가 깨닫지 못한 부분은 비동기 코드와 동기 코드가 근본적으로 다르기 때문에 동기 코드가 근본적으로 비동기 코드로 변경되지 않고서는 강제로 비동기 코드를 고수할 수 없다는 것입니다. yyx990803은 즉시 그것을 보았지만 그의 의견을 완전히 이해하는 데 시간이 걸렸습니다. 시간 내주셔서 감사합니다. 중간에 제 부분에서 잘못된 의사 소통이 있었다면 죄송합니다.

여기에 몇 가지 사용 사례가 있으며 몇 가지 제안 및 해결 방법을 얻고 싶습니다.

MainPage.vue 는 내 주요 컨테이너입니다. beforeCreate 에서 ajax "/init"를 호출하여 사용자 정보를 얻은 다음 Vuex.store에 커밋합니다.
Content.vue 는 MainPage.vue 내부의 자식입니다. Vuex.store에서 오는 사용자의 역할에 따라 mounted 단계에서 다른 api 호출을 호출하고 싶습니다.

async/await 흐름의 수명 주기 호출은 순서를 따릅니다.
부모 beforeCreate -> 부모 만들기 -> 자식 beforeCreate -> 자식 만들기 -> 자식 탑재 .... (구성 요소 수명 주기에 대해 올바르게 이해한 경우).

하지만 현재 Content.vue 에서 사용자 정보를 얻을 수 없습니다. 지금 해결 방법을 얻으려면 어떻게 해야 합니까?
많은 페이지(Vue-Router의 컨테이너)에서 사용되기 때문에 "/init" API를 MainPage.vue 내부에 유지하고 싶습니다.

stackoverflow에 게시 된 질문

감사 해요

가치가 있는 것에 대한 hackish 해결 방법:

{
  created: function(){
    this.waitData = asyncCall();
  },
  mounted: function(){
    this.waitData.then(function(data) { ... })
  }
}

가능한 더 "평평한" 솔루션:

{
    async created () {
        let createdResolve = null
        let createdReject = null
        this.createdPromise = new Promise(function(resolve, reject){
            createdResolve = resolve
            createdReject = reject
        })
        await asyncCall1()
        await asyncCall2()
        ...
        createdResolve(someResult)
    }
    async mounted () {
        let result = await this.createdPromise
        ...
    }
    data () {
        return {
            createdPromise: null
        }
    }
}

이건 아직 아닌건가요?

data() {
 ...
},
async created() {
  const something = await exampleMethod();
  console.log(something);
}

@fifman이 언급

@breadadams 네, 물론입니다. 함수 _inside_ created 메소드가 대기되지만 created 또는 mounted 함수 자체는 대기하지 않습니다.

뷰 인스턴스가 호출 그래서 created 즉각적를 mounted 의 긴 실행중인 프로세스의 앞에 created 완성됩니다

아 , 내 나쁜 @darren-dev - 다른 사용 사례가 있지만 지금 문제가 보입니다. 명확히 해 주셔서 감사합니다.

@breadadams 전혀 문제 없습니다 - 우리 모두는 우리 자신의 경우를 위해 여기에 있습니다. 명확히 할 수 있어서 기쁩니다!

비동기 수명 주기 후크는 다음 주 버전에서 좋은 구현이 될 수 있습니다.

수명 주기 방법에 대한 비동기 지원을 허용하면 기본적으로 나쁜 UX 관행을 조장할 것 같습니다. 어떻게? 비동기 함수는 즉시 완료할 수 없는 요청(예: 장기 실행 또는 네트워크 요청)에 사용됩니다. Vue가 생성 또는 탑재를 지연시키거나 네트워크 요청이나 장기 실행 비동기 프로세스를 기다리도록 다른 수명 주기 방법을 강제하면 사용자에게 눈에 띄는 영향을 미칩니다. 사용자가 사이트에 와서 빈 화면으로 4초 동안 기다려야 하는 동안 구성 요소가 사용자의 spotty cell 연결이 네트워크 요청을 완료하기를 기다리는 동안을 상상해 보십시오. 그리고 이것은 사용자에게 부정적인 영향을 미칠 뿐만 아니라 상황에 대한 통제력을 희생하고 있습니다. 사용자가 로드 시간을 더 빨리 인식하도록 하거나 확정 또는 확정되지 않은 진행률 표시기를 표시하기 위해 개발자로서 할 수 있는 일은 없습니다. 따라서 이 기능을 Vue에 구축한다고 해서 웹을 더 나은 곳으로 만드는 것은 아닙니다. 당신은 나쁜 관행을 활성화하고 있습니다.

처음부터 비동기식 사례를 계획하고 설계하는 것이 훨씬 낫습니다. created 또는 mounted 또는 어디에서든 비동기식 프로세스를 시작한 다음 구성 요소에 골격 구조를 갖도록 하거나 최악의 경우 API가 사용자의 권한을 반환할 때까지 기다리는 동안 스피너. 훨씬 더 나은 UX와 제어를 희생하지 않습니다. 그리고 Vue는 번들을 더 작게 유지하면서 비동기 수명 주기 기능을 처리하기 위해 코드를 추가할 필요가 없습니다. 승리 승리.

@seanfisher 유효한 지적을

면책 조항 : 다음은 페이지 생성을 염두에 두고 작성되었습니다. 내 주장이 유효하지 않은 유효한 사용 사례가 분명히 있습니다.

그러나 개발자의 디자인 패턴을 지시하는 것은 사용 중인 프레임워크에 맡겨서는 안 됩니다. 내 주장은 단계가 완료되기를 기다리고 있지 않다면 왜 다른 단계가 있습니까? 스테이지를 생성한 다음 탑재한 이유는 무엇입니까? 기본적으로 모든 것이 한 번에 진행된다면 생성된 단계는 완전히 무시해도 됩니다.

말 그대로, 내가 (초기 Vue 이후) 생성된 유일한 시간은 vue에 의존해야 하는 무언가를 주입해야 할 때였습니다. 이는 내 페이지의 설정이나 레이아웃과 아무 관련이 없었습니다. 그러나 페이지가 렌더링되기 _전에_ 훨씬 더 나은 (짧은) 비동기 작업이 실행될 때까지 기다려야 했습니다(예: Firebase의 인증 방법에 연결). 이를 생성한 다음 마운트하기 전에 완료될 때까지 기다리면 해킹된 해결 방법의 필요성이 완전히 줄어듭니다.

내 주장은 Vue가 내가 잘못 발전하고 있다고 말해선 안된다는 것입니다. 원하는 기능만 제공하면 됩니다.

그러나 개발자의 디자인 패턴을 지시하는 것은 사용 중인 프레임워크에 맡겨서는 안 됩니다.

음....프레임워크는 개발자를 특정 디자인 패턴 및 관행으로 특별히 제한하거나 안내하거나 "프레임"하도록 구축되었습니다. 그것이 그들의 주요 목적입니다. 모든 좋은 프레임워크는 스마트 API를 제공할 것입니다. 스마트 API는 프레임워크를 사용하는 명확하고 분명한 방법을 제공하지만 동시에 제한적이기도 합니다.

예, 프레임워크가 특정 기능을 제공하지만 동시에 개발자를 특정 디자인 방식으로 제한한다는 것은 역설적입니다. 바로 이것이 프레임워크 내에서 의견이 도움이 될 수도 있고 상처를 줄 수도 있는 부분입니다. 적절한 균형을 찾는 것이 어렵습니다. Vue 또는 Evan과 Vue 개발 팀이 이러한 판단을 내리는 데 큰 역할을 했고 훌륭하게 수행하고 있다고 생각합니다.

스콧

나는 잘 설계된 프레임워크가 동일한 디자인 패턴으로 확장되어야 한다고 주장하지는 않겠지만, 내 주장은 프레임워크가 그것을 지시할 수 없다는 것입니다. 당신 말이 맞아요. 하지만 프레임워크가 아무리 좋아도 최종 개발자는 그들이 원하는 것은 무엇이든 할 수 있도록 열려 있어야 합니다.

그러나 생성 및 탑재된 이벤트를 비동기식으로 만드는 _actual_ 인수에 대해서는 다루지 않았습니다. 방금 내 의견에 (틀리지 않은) 의견을 추가했는데, 이는 일반적으로 큰 탈선으로 이어집니다.

나는 잘 설계된 프레임워크가 동일한 디자인 패턴으로 확장되어야 한다고 주장하지는 않겠지만, 내 주장은 프레임워크가 그것을 지시할 수 없다는 것입니다.

죄송합니다. 하지만 이것은 나에게 의미가 없습니다. 어떻게 확장해야 하는지 지시하지 않는 하나의 프레임워크를 보여주세요.

'에반앤코가 판단을 잘한다'는 제 말이 제 의견이 될 거라고 생각했습니다. 하지만, 더 명확하게. 마운트 및 생성된 수명 주기 후크는 비동기식으로 작동할 필요가 없으며 동기식으로 작동한다는 사실이 애플리케이션 논리에 대한 추론에 도움이 됩니다. 어쨌든 모든 "대기"는 UI에서 설명되어야 하며 비동기 코드는 여전히 각 후크에서 실행될 수 있습니다. 우리는 이제 beforeMount와 마운트 후크가 필요한지에 대해 논쟁할 수 있습니다. 그러나 예를 들어 컴파일된 렌더 함수와 같이 생성된 상태에서 아직 액세스할 수 없는 마운트에 필요한 것이 한두 가지가 있을 수 있습니다.

스콧

Vue가 비동기 수명 주기 후크에 대해 어떤 식으로든 의견을 가지고 있다면 추측의 문제가 되어서는 안 됩니다. Vue가 채택, 제공 또는 권장하는 표준, API, 가이드 및 모범 사례가 언제 모든 사람이 읽을 수 있는지 추측할 필요가 없습니다.

Evan의 원래 답변에서 비동기 수명 주기 후크는 표준 API에 포함되어 있지 않은데, 이는 반드시 나쁜 생각이기 때문이 아니라 구현 비용을 정당화할 만큼 이점이 크지 않기 때문입니다.

사용자가 무언가가 일어나고 있다는 표시 없이 비동기 created 또는 기타 수명 주기 후크를 기다리게 하는 것은 나쁜 습관이라는 의견에 대해 Vue가 비동기 후크를 지원했기 때문에 이제 아마도 문제를 해결하고 구현하기 쉬울 수 있는 "단계 템플릿"이라고 부를 수 있는 것을 제공합니다.

사용자가 무언가가 일어나고 있다는 표시 없이 생성된 비동기식 또는 기타 수명 주기 후크를 기다리게 하는 것은 나쁜 습관이라는 의견에 대해,

이것도 정말 문제일까요?

스콧

여기에 내가 겪고 있는 문제가 있습니다. 그리고 이것이 문제가 있는 것처럼 보이기 때문에 누군가가 이 작업을 수행하는 방법을 제안할 수 있습니다.

우리의 Vue 애플리케이션(다소 큰)은 Vuex를 광범위하게 사용합니다. create() 라이프사이클의 Vue 구성 요소 중 상당수에서 store.dispatch()를 통해 상점의 일부 항목을 설정했습니다(분명히). 그러나 내 관심을 끌게 된 것처럼 store.dispatch()는 기본 논리와 함수가 비동기가 아닌 경우에도 항상 약속을 반환합니다. 그래서 async created() { await store.dispatch('foo/action') } 넣었지만 실제로는 실패했습니다.

나는 또한 Typescript를 사용하고 있으며 기다리지 않을 때 다소 심하게 불평합니다.

그렇다면 비동기화할 수 없을 때 수명 주기에서 Vuex store.dispatch()를 사용하는 가장 좋은 방법은 무엇입니까?

건배!!

vue의 특정 의견에 대한 다른 모든 토론과 프레임워크가 의견을 제쳐두고 이 동작을 더 명확하게 문서화하는 것이 도움이 될 수 있습니다.

위의 @fifman 의 "더 플랫한" 솔루션을 보고 있는데 이것이 문제를 해결하는지 확신할 수 없습니다. mounted() 반환될 때까지 내 XHR을 로드했는지 확인합니다. 해당 솔루션에서 created() 및 mounted() 는 모두 비동기이므로 Vue는 각각을 호출하고 백그라운드에서 비동기 작업이 진행되는 동안 거의 즉시 반환됩니다. 사실 createdPromise 없애고 created() 또는 mounted() 에서 모든 비동기 작업을 수행하는 것보다 다음과 같은 방법이 더 나은지 잘 모르겠습니다.

async mounted() {
  let response = await fetch(my_url)
  let data = await response.text()
  my_data_member = data
}

어쨌든 mounted() 가 Promise를 반환한 후 오랜 시간이 지난 후 XHR이 완료되면 my_data_member 가 "나중에" 채워집니다.

루트 구성 요소 <div id="app"/> v-if 를 사용하고 데이터 로드가 완료되면 트리거할 수도 있습니다. 예를 들어 새로 고침 토큰에 사용합니다.

이것은 많은 사용 사례를 갖고 있는 멋진 기능입니다. 내 사용 사례의 경우 구성 요소의 실제 렌더링 전에 특정 API 속성을 로드해야 합니다. 그러나 라이프 사이클 후크의 비동기가 이상적인 솔루션이라고 생각하지 않습니다.

현재 모든 사람들이 여기에서 비동기 기능이 원활하게 실행되는 완벽한 시나리오를 언급하고 있습니다. 그러나 예를 들어 사용자 연결이 느리거나 지연되고 API 응답 후 구성 요소가 마운트되기를 기다리는 경우 전체 구성 요소 수명 주기가 분산됩니다. 사용자에게 로딩 정보를 표시할 수 없습니다. 또는 훨씬 더 나쁜 것은 API가 시간 초과되거나 오류를 반환하면 응용 프로그램이 탑재되지 않고 중단된다는 것입니다.

이것은 멋진 기능이지만 프레임워크보다 애플리케이션에서 처리하는 것이 좋습니다. 도메인 로직 구현은 프레임워크보다 기본 로직에 대한 통찰력이 더 많기 때문에 부작용이 적습니다.

이 기능에 대해 +1입니다.
다양한 구성 요소에서 사용하는 믹스인이 있습니다. 믹스인은 마운트된 후크의 데이터베이스에서 데이터를 가져옵니다.
구성 요소는 마운트된 후크에서도 믹스인이 가져온 데이터와 함께 작동해야 합니다.
지금과 같이 믹스인이 데이터 로드를 완료하고 구성 요소에서 마운트된 후크를 버릴 때 호출될 콜백을 구현해야 했습니다.
작동하지만 마운트된 후크가 약속을 처리하면 더 이쁠 것입니다.

@cederron 순전히 관심이 없는데 왜 부모 구성 요소의 데이터를 다운로드하여 소품으로 전달할 수 없습니까? v-if 를 사용하여 데이터가 로드되는 동안 로드 표시기를 표시하고 데이터가 표시되면 구성 요소를 표시할 수 있으며 구성 요소가 생성되면 필요한 모든 데이터를 갖게 됩니다.

구성 요소가 두 가지 별개의 관련 없는 상태를 나타내지 않도록 합니다('데이터가 로드되지 않음, 대기 중' 및 '데이터가 로드되었습니다. 조작할 수 있음').

여러 위치에서 로직을 재사용해야 하는 경우 다운로드 로직을 Vuex로 이동할 수도 있습니다.

@ReinisV 제 경우를 너무 단순화한 것
따라서 mixin은 데이터베이스에서 데이터를 가져와야 합니다. > 구성 요소가 데이터베이스에서 데이터를 생성합니다. > 이제 구성 요소가 표시됩니다.

AFAIK이 작동하지 않습니다.

export const MyMixin = {
    data: function () {
        return {
            dbData: null
        }
    },
   mounted:  async function () {
      this.dbData = await asyncFetchDataFromDB()
   }
}


export const MyComponent = {
    mixins: [MyMixin],
    data: function () {
        return {
            newData: null
        }
    },
   mounted:  function () {
      this.newData = handleDBData(this.dbData)
   }
}

dbData는 구성 요소 마운트 후크에서 null이 됩니다.

현재 mixin이 데이터를 가져올 때 콜백을 실행하지만 마운트 기능을 비동기식으로 만드는 것이 더 나을 것입니다.

vuex를 사용하지 않기 때문에 vuex에 대해 많이 말할 수 없습니다.

@seanfisher가 여기서 언급한 것을 싶습니다 . 비동기로 표시된 구성 요소에 대한 vue 대기는 사용자에게 문제를 일으킬 뿐만 아니라 데이터 조회를 시작하기 위해 async/await를 사용하는 패턴이 어디에나 존재합니다. vue를 차단하는 것을 명시적으로 피하기 위해 이러한 수명 주기 후크의 코드를 대기되지 않은 약속으로 명시적으로 변환합니다. 어떤 경우에는 좋을 수도 있고 기능이 도입된다면 구성 요소 후크 실행을 처리하는 현재 수명 주기와 전역 콜백에 대한 실행을 기다리는 수명 주기의 두 가지 수명 주기를 동시에 실행하는 것이 좋습니다.

하지만 vue 차단을 피하기 위해 모든 라이프사이클 후크를 문자 그대로 다시 작성하는 것은 정말 실망스러울 것입니다. async/await 는 훨씬 깨끗하므로 약속을 사용하지 않습니다. 이전 버전과 호환되지 않는 방식으로 이것을 변경하면 실패의 구덩이에 대한 성공의 구덩이(대기하지 않는 구성 요소 수명 주기)가 변경됩니다.

처음부터 비동기식 사례를 계획하고 설계하는 것이 훨씬 낫습니다. created 또는 mounted 또는 어디에서든 비동기식 프로세스를 시작한 다음 구성 요소에 골격 구조를 갖도록 하거나 최악의 경우 API가 사용자의 권한을 반환할 때까지 기다리는 동안 스피너. 훨씬 더 나은 UX와 제어를 희생하지 않습니다. 그리고 Vue는 번들을 더 작게 유지하면서 비동기 수명 주기 기능을 처리하기 위해 코드를 추가할 필요가 없습니다. 승리 승리.

@seanfisher 감사합니다. 매우 유용합니다!

비동기 호출이 반환된 경우에만 렌더링되는 비동기 구성 요소를 대신 사용하지 않는 이유는 무엇입니까?
API에 대한 자세한 정보는 여기
https://vuejs.org/v2/guide/components-dynamic-async.html#Async -구성 요소

new Vue({
  components: {
    root: () => ({ // Aync component
      // The component to load (should be a Promise)
      component: new Promise(async function (resolve) {
        await FetchMyVariables()
        resolve(MyComponent) // MyComponent will be rendered only when FetchMyVariables has returned
      }),
      // A component to use while the async component is loading
      loading: { render: (h) => h('div', 'loading') }, 
    })
  },
  render: h => h('root')
})

이러한 솔루션의 대부분은 괜찮아 보이지만 이것이 Vue를 매우 직관적으로 만드는 주요 누락 부분 중 하나라고 생각합니다. async await를 사용하는 것이 이제 일상적인 일이 되었기 때문에 Vue 3에서 이것을 구현해야 한다고 생각합니다. SO PLEASE @yyx990803 Vue 3에서 합시다. PLEEEEEEEASE. 전체 VUE 아키텍처는 이러한 경우를 가정하지 않고 만들어졌으며 사람들이 여기에 게시하는 대부분의 내용은 해결 방법 및 해킹입니다. 후크는 실제로 비동기 함수를 존중해야 하고 다음 후크 함수로 전달되는 반환 값도 기대해야 한다고 생각합니다.

내 코드를 리팩토링하려고 하는데 이것이 인정받지 못하고 있지만 해킹이 될 것이기 때문에 못생긴 코드가 나올 것입니다.

수명 주기 방법에 대한 비동기 지원을 허용하면 기본적으로 나쁜 UX 관행을 조장할 것 같습니다. 어떻게? 비동기 함수는 즉시 완료할 수 없는 요청(예: 장기 실행 또는 네트워크 요청)에 사용됩니다. Vue가 생성 또는 탑재를 지연시키거나 네트워크 요청이나 장기 실행 비동기 프로세스를 기다리도록 다른 수명 주기 방법을 강제하면 사용자에게 눈에 띄는 영향을 미칩니다. 사용자가 사이트에 와서 빈 화면으로 4초 동안 기다려야 하는 동안 구성 요소가 사용자의 spotty cell 연결이 네트워크 요청을 완료하기를 기다리는 동안을 상상해 보십시오. 그리고 이것은 사용자에게 부정적인 영향을 미칠 뿐만 아니라 상황에 대한 통제력을 희생하고 있습니다. 사용자가 로드 시간을 더 빨리 인식하도록 하거나 확정 또는 확정되지 않은 진행률 표시기를 표시하기 위해 개발자로서 할 수 있는 일은 없습니다. 따라서 이 기능을 Vue에 구축한다고 해서 웹을 더 나은 곳으로 만드는 것은 아닙니다. 당신은 나쁜 관행을 활성화하고 있습니다.

처음부터 비동기식 사례를 계획하고 설계하는 것이 훨씬 낫습니다. created 또는 mounted 또는 어디에서든 비동기식 프로세스를 시작한 다음 구성 요소에 골격 구조를 갖도록 하거나 최악의 경우 API가 사용자의 권한을 반환할 때까지 기다리는 동안 스피너. 훨씬 더 나은 UX와 제어를 희생하지 않습니다. 그리고 Vue는 번들을 더 작게 유지하면서 비동기 수명 주기 기능을 처리하기 위해 코드를 추가할 필요가 없습니다. 승리 승리.

수천의 하나의 의견. 지연되는 구성 요소 렌더링이 긍정적인 사용자 경험과 함께 살 수 있는 시나리오를 상상할 수 없다고 해서 그것이 존재하지 않는다는 의미는 아닙니다.

프레임워크가 개발자와 싸우면 개발자는 다른 프레임워크를 찾을 것입니다.

@robob4him

수천의 하나의 의견. 지연되는 구성 요소 렌더링이 긍정적인 사용자 경험과 함께 살 수 있는 시나리오를 상상할 수 없다고 해서 그것이 존재하지 않는다는 의미는 아닙니다.

프레임워크가 개발자와 싸우면 개발자는 다른 프레임워크를 찾을 것입니다.

당신은 절대적으로 옳습니다. 그러나 여기서 공유한 어떤 것도 문제를 어떤 식으로든 해결할 수 있는 유효한 주장이 아닙니다. 커뮤니티가 기능을 개발하도록 강요하기 위해 겁을 주는 전술을 도입했습니다. 대화의 건설적인 연속이 아닙니다.

@wparad , 그것은 절대적으로 겁을 주는 전술이지만 누군가에게 무엇을 하도록 강요하지는 않을 것입니다. 기능이 나쁜 습관이나 반패턴을 지원하거나 더 큰 개발자 커뮤니티를 썩게 할 것이라는 주장을 하는 것은 겁을 주는 전술입니다.

말 그대로 모든 프레임워크/언어의 기능 중 절반은 개발자에게 위험합니다. public 메서드를 확장할 수 있고 Vue는 요소($el)에 대한 액세스를 권장합니다. 하루가 끝나면 개발자가 작업을 완료해야 하기 때문에 프레임워크는 이러한 것들을 제공합니다.

이 기능 요청은 1년 된 것입니다. 사람들은 그 이유가 실제로 나쁜 습관을 일으키기 때문이 아니며 지연된 렌더링을 나쁜 습관으로 인식해서는 안된다는 것을 이해해야 합니다.

vue와 함께 requirejs를 사용해야 합니다. 내가 requirejs를 좋아하는 것이 아니라 모든 모듈을 AMD 모듈로 포함하는 오픈 소스 LMS와 함께 vue를 사용하고 싶기 때문입니다. beforeCreate 후크에서 필요한 모든 라이브러리를 로드할 수 있다면 좋을 것입니다. 현재 나를 위한 대안은 vue 외부에서 로드한 다음 더 지저분한 전달하는 것입니다.

수명 주기 방법에 대한 비동기 지원을 허용하면 기본적으로 나쁜 UX 관행을 조장할 것 같습니다. 어떻게? 비동기 함수는 즉시 완료할 수 없는 요청(예: 장기 실행 또는 네트워크 요청)에 사용됩니다. Vue가 생성 또는 탑재를 지연시키거나 네트워크 요청이나 장기 실행 비동기 프로세스를 기다리도록 다른 수명 주기 방법을 강제하면 사용자에게 눈에 띄는 영향을 미칩니다. 사용자가 사이트에 와서 빈 화면으로 4초 동안 기다려야 하는 동안 구성 요소가 사용자의 spotty cell 연결이 네트워크 요청을 완료하기를 기다리는 동안을 상상해 보십시오. 그리고 이것은 사용자에게 부정적인 영향을 미칠 뿐만 아니라 상황에 대한 통제력을 희생하고 있습니다. 사용자가 로드 시간을 더 빨리 인식하도록 하거나 확정 또는 확정되지 않은 진행률 표시기를 표시하기 위해 개발자로서 할 수 있는 일은 없습니다. 따라서 이 기능을 Vue에 구축한다고 해서 웹을 더 나은 곳으로 만드는 것은 아닙니다. 당신은 나쁜 관행을 활성화하고 있습니다.

처음부터 비동기식 사례를 계획하고 설계하는 것이 훨씬 낫습니다. created 또는 mounted 또는 어디에서든 비동기식 프로세스를 시작한 다음 구성 요소에 골격 구조를 갖도록 하거나 최악의 경우 API가 사용자의 권한을 반환할 때까지 기다리는 동안 스피너. 훨씬 더 나은 UX와 제어를 희생하지 않습니다. 그리고 Vue는 번들을 더 작게 유지하면서 비동기 수명 주기 기능을 처리하기 위해 코드를 추가할 필요가 없습니다. 승리 승리.

당신이 말하는 것은 v-if/v-clock/v-show 기능을 추가하면 나쁜 관행을 조장하므로 해당 기능을 제거하여 프레임워크를 더 잘 속일 수 있다는 것입니다. 그런 다음 3개의 지시문을 넣지 않기 위해 Vue가 더 작아지도록 복잡한 접근 방식을 사용하여 동일한 작업을 수행합니다. 1차 개발자는 바보가 아니다. 두 번째 바보 방지 프레임 워크는 차례로 명백한 "바보"를 기반으로 수행 할 수있는 작업을 제한하기 때문에 사용성을 제한합니다. 전체 화면을 공백으로 두고 비동기 작업을 통해 전체 웹 사이트를 차단하도록 v-if 를 넣는 이유는 무엇입니까?

대부분의 사용 사례가 빈 페이지가 없을 수도 있다는 사실을 무시하고 있다고 생각합니다. 그런 이유로 구성 요소 라고 v-if 에 의해 차단되고 무언가가 변경될 때 트리거되는 구성 요소일 수 있습니다. 단, 처음 랜더링을 하는 과정에서 async functions 등은 컴포넌트가 부팅될 때 지켜져야 합니다. 나는 이것을 찾기 위해 전체 Vue 문서를 샅샅이 살펴보았고 마침내 위의 해킹 예제와 같이 그다지 좋지 않은 해결 방법으로 작업을 수행했습니다.

나를 걱정시키는 것은 누군가/나중에 내가 코드를 유지하는 것입니다. Promise 콜백 지옥 대 Async ... 기다립니다.

실제로 나는 그것이 프레임워크의 유연성과 제어 가능성을 쉽게 후속 조치하는 방식으로 향상시키는 것을 봅니다. 내가 의미하는 바를 보려면 위의 해킹을 살펴보십시오. 예를 들어 개발자는 간단한 async mounted () { await... } 문의 공백을 채우기 위해 모든 작업을 수행합니다. 이러한 기능을 사용하지 않으려면 함수를 async 로 정의하지 않거나 await 를 전혀 사용하지 마십시오.

실제로 async mounted 라이프사이클 후크를 실제로 사용하는 사람은 자신이 하는 일과 그 일을 하는 이유를 이해하고 여러분이 걱정하는 나쁜 습관을 만들지 않을 것입니다.

@emahuni , 나는 당신이 공유하는 기대에 동의하지 않을 것이라고 생각하지 않지만, 뉘앙스가 있다고 생각합니다. async mounted 또는 async created 가 구성 요소의 렌더링을 지연한다고 가정해 보겠습니다. 이 경우 부모는 무엇을합니까? 수행:

• 차단도
• 구성 요소가 로드가 완료될 때까지 DOM v-if 제거한다고 가정합니다.
• 로드가 완료될 때까지 구성 요소가 숨겨져 있다고 가정합니다.
• 그 자리에 임시 요소를 표시하시겠습니까?

동적으로 로드된 구성 요소에 대한 기대치가 일관적이라는 데 동의하지만 부모에 대한 동작은 그렇지 않을 것이라고 생각합니다. 이러한 경우 IMO는 자식 구현을 부모에게 노출하고 부모가 해당 동적 구성 요소로 무엇을 해야 하는지 알아내도록 강제하는 것입니다. 대신 데이터가 로드되는 방식과 자식 구성 요소의 상태는 자식에게 달려 있어야 합니다. 비동기를 로드하는 경우 Vue에 무엇을 그 자리에 렌더링해야 하는지(또는 렌더링하지 않아야 하는지) 설명할 방법이 필요합니다. 이를 처리하는 가장 좋은 방법은 새로운 복잡성을 도입하는 것보다 프레임워크가 이미 작동하는 방식입니다.

또한, 나는 당신의 주장을 완전히 따르지 않습니다.

당신이 말하는 것은 v-if/v-clock/v-show 기능을 추가하면 나쁜 관행을 조장하므로 해당 기능을 제거하여 프레임워크를 더 잘 속일 수 있다는 것입니다.

이 경우 마운트를 기다리거나 생성된 비동기 구성 요소를 도입하면 나쁜 습관 이 발생한다는 것을 분명히 알 수 있지만 이것이 실제로 발생하는지 확실하지 않습니다. 둘째, 그것이 나쁜 습관을 일으키더라도 새로운 나쁜 습관을 만들기 위한 정당화로 사용하기보다는 그것을 고칠 것을 선택해야 한다는 질문을 던지고 있습니다. v-if 등에 의해 생성되는 나쁜 관행을 알고 있다면... 정당화로 사용하려고 하기 보다는 문제가 무엇인지 명시적으로(물론 다른 문제에서) 공유하도록 초대합니다. 다른 토론을 위해.

@emahuni , 나는 당신이 공유하는 기대에 동의하지 않을 것이라고 생각하지 않지만, 뉘앙스가 있다고 생각합니다. async mounted 또는 async created 가 구성 요소의 렌더링을 지연한다고 가정해 보겠습니다. 이 경우 부모는 무엇을합니까? 수행:

• 차단도

부모는 자식을 기다리지 않고 계속해서 렌더링할 수 있습니다. 왜 그래야 합니까? 자식이 렌더링되면 바로 진행할 수 있으며 updated 실행할 수 있습니다.

• 구성 요소가 로드가 완료될 때까지 DOM v-if 제거해야 한다고 가정합니다.

내가 이것을 얻을 수 있을지 확신이 서지 않지만... 대답은 아니오입니다. 우리는 그것이 제거될 것이라고 가정하지 않습니다. 단지 그 시간 동안 마운트를 차단해야 하는 마운트 중에 무엇인가를 수행해야 합니다. 위에서 읽은 많은 사용 사례가 있습니다.

• 로드가 완료될 때까지 구성 요소가 숨겨져 있다고 가정합니다.

이것은 개발자, 왜 마운트된 후크 또는 다른 후크를 비동기화하는지에 따라 다릅니다.

• 그 자리에 임시 요소를 표시하시겠습니까?

전혀 그렇지 않을 수도 있습니다. 다시 말하지만 그것은 개발자가 달성하고자 하는 바에 달려 있습니다. 요점은 어떤 것도 스트레이트 재킷을 입어서는 안 된다는 것입니다. 예를 들어, v-if 가 설계되었을 때 누군가가 매번 구성 요소의 렌더링을 차단하려는 이유와 대신 배치하고 실수 방지할 수 있는 항목을 생각했기 때문이 아닙니다. 개발자 디자인에 의해 v-if 에 잘못될 수 있는 많은 것들이 있습니다. 그 시간 동안 화면에 무엇이 나올지 걱정할 필요가 없습니다. 프레임워크가 걱정할 일이 아닙니다.

동적으로 로드된 구성 요소에 대한 기대치가 일관적이라는 데 동의하지만 부모에 대한 동작은 그렇지 않을 것이라고 생각합니다. 이러한 경우 IMO는 자식 구현을 부모에게 노출하고 부모가 해당 동적 구성 요소로 무엇을 해야 하는지 알아내도록 강제하는 것입니다. 대신 데이터가 로드되는 방식과 자식 구성 요소의 상태는 자식에게 달려 있어야 합니다. 비동기를 로드하는 경우 Vue에 무엇을 그 자리에 렌더링해야 하는지(또는 렌더링하지 않아야 하는지) 설명할 방법이 필요합니다. 이를 처리하는 가장 좋은 방법은 새로운 복잡성을 도입하는 것보다 프레임워크가 이미 작동하는 방식입니다.

FYI: 당신은 이것이 구현되어야 한다는 데 동의하지만, 당신이 울고 있는 이러한 복잡성을 도입할 것이고 그는 Vue 3보다 브레이킹 체인지가 도입될 때 나중에 수행될 수 있다고 생각합니다. 요점은 그가 필요하다고 느낀다는 것입니다. .

또한, 나는 당신의 주장을 완전히 따르지 않습니다.

당신이 말하는 것은 v-if/v-clock/v-show 기능을 추가하면 나쁜 관행을 조장하므로 해당 기능을 제거하여 프레임워크를 더 잘 속일 수 있다는 것입니다.

이 경우 마운트를 기다리거나 생성된 비동기 구성 요소를 도입하면 나쁜 습관 이 발생한다는 것을 분명히 알 수 있지만 이것이 실제로 발생하는지 확실하지 않습니다. 둘째, 그것이 나쁜 습관을 일으키더라도 새로운 나쁜 습관을 만들기 위한 정당화로 사용하기보다는 그것을 고칠 것을 선택해야 한다는 질문을 던지고 있습니다. v-if 등에 의해 생성되는 나쁜 관행을 알고 있다면... 정당화로 사용하려고 하기 보다는 문제가 무엇인지 명시적으로(물론 다른 문제에서) 공유하도록 초대합니다. 다른 토론을 위해.

나는 단지 async... 대해 말한 것과 유사한 구성 요소의 렌더링을 차단하는 데 잘못 사용될 수 있는 기능의 예로 이러한 지시문을 지적했습니다. 아무 문제가 없습니다. 그렇다면 누군가가 "나쁜 관행"을 사용하여 잠시 동안 빈 페이지를 표시하는 구성 요소를 만들 수 있기 때문에 이러한 지시문을 제거해야 합니까? 실제로 그런 일은 일어나지 않기 때문에 그렇게 하는 사람을 볼 수 없습니다. 끔찍할 정도로 가장 나쁜 예를 들려고 하지 않는 한 말입니다.

요점은 아직 사용 사례를 볼 수 없다면 다른 사람들이 그것을 나쁘게 사용할 것이라고 말하지 마십시오. 따라서 해서는 안 됩니다. 나쁜 습관은 무지의 문제이며 무지한 사람은 이러한 기능을 전혀 사용하지 않을 수 있습니다.

누군가가 https://github.com/vuejs/vue/issues/7209#issuecomment -424349370 위에 질문했는데 내가 본 한 아무도 그에게 대답하지 않았습니다. 이것은 Vue가 이 부분에서 뒤처지고 있음을 진정으로 보여줍니다. 아키텍처의 이 부분은 아직 비동기가 아니었을 때 설계되었습니다. 따라서 현대 아키텍처에 대한 최신 요구 사항을 충족하도록 업데이트하는 것은 좋은 생각입니다. 그렇지 않으면 나머지는 업계에서 일어나고 있는 일을 하는 것보다 그것을 수행하는 특정 방법을 필요로 하는 해킹 및 해결 방법입니다.

하지만 아직 확실하지는 않지만 새로운 기능적 API를 한 눈에 보면 실제로 그렇게 할 수 있을 것 같습니다. 기능적이기 때문에 비동기 수명 주기 후크와 같이 객관적으로 할 수 없는 특정 작업을 수행할 수 있음을 의미합니다.

요점은 아직 사용 사례를 볼 수 없다면 다른 사람들이 그것을 나쁘게 사용할 것이라고 말하지 마십시오. 따라서 해서는 안 됩니다. 나쁜 습관은 무지의 문제이며 무지한 사람은 이러한 기능을 전혀 사용하지 않을 수 있습니다.

그 점을 지적한 적이 없습니다. 구성 요소가 렌더링되는 것을 차단하지 않고 기본적으로 비동기 작업을 수행하고 싶다는 점을 강조하고 있습니다. mounted 또는 created 블록에서 async 작업을 수행하면 구성 요소 렌더링이 지연된다는 것은 직관적이지 않습니다. 이것이 사실이라고 가정하면 대신 현재 기능을 원하는 소비자가 진행하는 방식에서 복잡성이 발생하는 것을 볼 수 있습니다. 지금까지의 주장은 요구되는 것이 수행될 수 없다는 것이 아니라 요구되는 것이 기본값이어야 한다는 것입니다. v-if="loaded" 기반으로 표시된 템플릿을 전환하여 구성요소의 렌더링을 이미 차단할 수 있습니다.

지금 코드를 차단하지 않고 렌더링하려면 다음과 같습니다.
현재 해당 코드는 다음과 같습니다.

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
    this.loaded = true;
  }
</script>

차단으로 렌더링하는 것은 실제로 차단할 수 없기 때문에 똑같은 방식으로 보입니다. async created() 실제로 구성 요소를 차단했다고 가정합니다. 그런 다음 이제 코드가 분리되었습니다. 스피너를 표시하기 위해 다음과 같이 작성합니다.

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  created() { 
    this.loadData().then(() => this.loaded = true);
  }
</script>

그리고 우리가 작성하는 화면에서 구성 요소를 렌더링하는 것을 무시하십시오.

<template>
  <div>  
    <div>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
  }
</script>

렌더링을 차단하기 위해 이러한 단순화를 추가하면 차단을 더 복잡하게 만들지 않는 것이 어떤 이점이 있습니까? 나는 단지 그것을 보지 않고 있다.

구성 요소에 대한 종속성 처리

@yyx990803 꼭

다음은 수명 주기 후크에 비동기식 ... await가 있는 경우 우아하게 처리될 수 있는 사용 사례입니다.
_나는 실제로 앱에서 이것을 하고 싶었고 이것을 달성하기 위해 못생긴 코드를 얻었습니다. 이것은 coz_의 매우 인위적인 예입니다.

자신을 마운트하기 전에 구성 요소 B && C의 mounted 후크가 실행될 때 까지 기다리려면 구성 요소 A 가 필요합니다. 따라서 구성 요소 A의 mounted 는 created 후크를 기다려야 하며, 이는 트리거를 기다리고 있던 구성 요소 B 및 C 의 마운트를 트리거했습니다_(대기 전에 실제로 무언가를 할 수 있음)_. 문제는 이 방법이 더 쉽고 관련 구성 요소에 대해 모든 것이 한 곳에 있기 때문에 훨씬 깨끗하고 직관적입니다.

A 는 트리거 이벤트를 내보내고 B 와 C의 응답을 수신합니다. _( B 와 C는 계속하기 전에 A 의 신호를 기다리고, 일단 마운트되면 이벤트를 내보냅니다)_ 계속하기 전에 간단합니다. 이는 상태 관리를 위해 다른 곳에 흩어져 있는 관련 없는 데이터가 없는

주요 호스팅 구성 요소 , 모든 구성 요소가 함께 로드되지만 이벤트 및 비동기를 사용하여 올바른 구성 요소를 기다립니다... 기다립니다. 이 아이들이 무엇을 하는지는 덜 신경쓰고 스스로 명령합니다.

<template>
  <div>
     ...
     <component-A/>
     <component-B/>
     <component-C/>
     ... other conent
  </div>
</template>
<script>
  import ComponentA...
  ...
  export default {
      components: { ComponentA... }
  }
</script>

구성 요소 A 는 B와 C의 장착을 종속 항목으로 제어합니다. 트리거는 나중에 다른 후크에서 또는 동일한 구성 요소의 UX 이벤트를 통해 수행될 수 있습니다. 다음은 여기에서 아이디어를 보여주기 위한 것입니다.

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here before mounting thrusters, even await it
         this.root.$emit('mount-thrusters');
         await Promise.all([
            this.wasMounted('thruster-1-mounted'), 
            this.wasMounted('thruster-2-mounted')
         ]); 
      },
      mounted() {
        // will only run after components B and C have mounted
        ...
      },

     methods: {
       wasMounted(compEvent) {
          return new Promise( (resolve)=>this.root.$once(compEvent, ()=>resolve()));
       }
    }
  }
</script>

성분 B

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-1-mounted');
    }
  }
</script>

성분 C

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-2-mounted');
    }
  }
</script>

위의 코드는 많은 중복 코드 스니펫이 있음을 확인하는 믹스인으로 더 단순화할 수 있습니다. 저는 그냥 명확하게 하고 싶었습니다. wasMounted 메서드는 믹스인에 포함할 수 있으며 3가지 구성 요소 모두에서 사용할 수 있습니다.

여기서 우리는 동일한 것을 제어하기 위해 다른 곳에 흩어져 있는 다른 해킹 또는 라우터 코드 없이 각 구성 요소가 기대하는 것을 명확하게 볼 수 있습니다. 이 기능 없이 실제로 이 작업을 수행하는 것은 매우 혼란스럽습니다. 앱에서 이 작업을 수행했다고 생각합니다.

이것은 분명히 불필요하게 복잡하고 유지 관리할 수 없는 코드를 제거합니다.

이제 다르게 동작하는 32개의 추진기 구성 요소가 있는 대형 앱에서 이것을 상상해 보십시오. 믹스인을 넣으면 2개로 줄일 수 있는 약 3개의 포인트만 생각할 수 있습니다.

신선함을 유지하기

이는 마운트 및 생성에만 국한되지 않고 실제로 다른 모든 수명 주기 후크와 함께 작동해야 합니다. 이것이 반짝이는 새로운 beforeActivate / beforeUpdate 후크에 있다고 상상해보십시오. 우리는 구성 요소를 만들 수 await를 _activation / update_ 만 _activate / update_ 다과 구성 요소가 _activated / 업데이트 됨을 때마다 완료되면; 신선한 상태를 유지합니다.

일단 이것이 구현되면 목록은 끝이 없습니다.

요점은 아직 사용 사례를 볼 수 없다면 다른 사람들이 그것을 나쁘게 사용할 것이라고 말하지 마십시오. 따라서 해서는 안 됩니다. 나쁜 습관은 무지의 문제이며 무지한 사람은 이러한 기능을 전혀 사용하지 않을 수 있습니다.

그 점을 지적한 적이 없습니다. 구성 요소가 렌더링되는 것을 차단하지 않고 기본적으로 비동기 작업을 수행하고 싶다는 점을 강조하고 있습니다. mounted 또는 created 블록에서 async 작업을 수행하면 구성 요소 렌더링이 지연된다는 것은 직관적이지 않습니다. 이것이 사실이라고 가정하면 대신 현재 기능을 원하는 소비자가 진행하는 방식에서 복잡성이 발생하는 것을 볼 수 있습니다. 지금까지의 주장은 요구되는 것이 수행될 수 없다는 것이 아니라 요구되는 것이 기본값이어야 한다는 것입니다. v-if="loaded" 기반으로 표시된 템플릿을 전환하여 구성요소의 렌더링을 이미 차단할 수 있습니다.

지금 코드를 차단하지 않고 렌더링하려면 다음과 같습니다.
현재 해당 코드는 다음과 같습니다.

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
    this.loaded = true;
  }
</script>

차단으로 렌더링하는 것은 실제로 차단할 수 없기 때문에 똑같은 방식으로 보입니다. async created() 실제로 구성 요소를 차단했다고 가정합니다. 그런 다음 이제 코드가 분리되었습니다. 스피너를 표시하기 위해 다음과 같이 작성합니다.

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  created() { 
    this.loadData().then(() => this.loaded = true);
  }
</script>

그리고 우리가 작성하는 화면에서 구성 요소를 렌더링하는 것을 무시하십시오.

<template>
  <div>  
    <div>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
  }
</script>

렌더링을 차단하기 위해 이러한 단순화를 추가하면 차단을 더 복잡하게 만들지 않는 것이 어떤 이점이 있습니까? 나는 단지 그것을 보지 않고 있다.

이것은 Vue 101 부트캠프이고 거기에는 새로운 것이 없습니다. 예를 들어 위의 경우를 다루기에 충분하지 않습니다. 여기서 아이디어는 Vue가 실제로 사용되는 사용자 영역의 복잡성을 줄이고 추론 코드에 더 쉽게 사용할 수 있다는 것입니다.

여기서 렌더링은 문제가 아니라 실제로 결과가 렌더링되기 전에 일어나는 일입니다. 우리는 구성 요소를 진행하거나 렌더링하기 전에 작업을 수행할 수 있는 자유를 원합니다. 어쨌든 이것은 렌더링 차단과 전혀 관련이 없습니다. Vue가 지원하는 많은 수명 주기 후크가 있으며 다른 후크에 대해 비동기 코드를 처리하는 방법이 있다면 실제로 유용할 수 있습니다. 아이디어는 Vue가 다음 후크 기능으로 이동하기 전에 내부적으로 비동기를 존중하는 것입니다.

B & C를 A에 연결하는 대신 코드를 A.js에 "로드 A"로 이동한 다음 A.js가 "B.data" 및 "C.data"를 업데이트하도록 하는 것이 정말 혼란스럽습니다. . 그렇게 하면 어떤 이유로든 A.data가 변경되면 다른 구성 요소가 위임을 시도하지 않고 자동으로 다시 렌더링됩니다.
한 구성 요소에서 다른 구성 요소로 제어합니다. 공유된 경우에도 여전히 데이터를 분리하여 구성 요소 A 에서 A를 렌더링합니다. 우리는 fetchData 및 hasInitialized 와 같은 메서드가 포함된 단일 클래스를 사용했으며, 후자는 약속이고 전자는 후자를 해결합니다.
구성 요소를 직접 연결하면 구성 요소를 재사용할 수 없고 vue가 올바르게 다시 렌더링할 수 없도록 하는 예기치 않은 종속성 트리가 생성됩니다.

또는 전역 범위가 아니라 A, B, C의 부모에게 직접 이벤트를 emit 하고 부모가 B와 C를 렌더링할지 여부를 결정하도록 합니다.

  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

이 경우 B와 C가 렌더링되기 전에 실제로 렌더링해야 하는 A에 대한 것은 무엇입니까? created() 메서드에 항목이 있는 경우 JavaScript 클래스를 통해 또는 store 모듈을 사용하여 저장소를 채우는 것을 방해하는 것은 없습니다. 그러나 명시적 사용 사례가 더 도움이 됩니다. 즉, 캡처할 수 없는 사용자 스토리의 UX는 무엇입니까?

아이디어는 Vue가 다음 후크 기능으로 이동하기 전에 내부적으로 비동기를 존중하는 것입니다.

물론 그 부분은 이해가 되지만 예제가 복잡해야 하는 이유를 잘 모르겠습니다. 다음과 같은 사용자 스토리를 말해보세요.

내 구성 요소에는 async beforeMount 및 async mounted 가 모두 있지만 beforeMount 의 코드가 완료되기 전에 mounted 의 코드가 실행됩니다. beforeMount 가 완료되기 전에 mounted 되는 것을 어떻게 차단할 수 있습니까?

이것은 원래 요청의 일종이므로 두 번째 응답에서 제기된 질문은 여전히 ​​관련이 있다고 생각합니다. https://github.com/vuejs/vue/issues/7209#issuecomment -350284784

지금은 종료되지만 보다 구체적인 추론/사용 사례/영향을 자유롭게 후속 조치를 취하십시오.

실제로 이전에 실행된 수명 주기 후크를 차단해야 하는 유효한 사용 사례가 있습니까, 아니면 수명 주기 후크를 동기식으로 설정하는 것이 올바른가요? 지금까지 토론은 본질적으로 철학적이었지만(좋은 아키텍처 토론이 그러하듯이) 실제로 문제는 이렇게 하는 데 실제로 합당한 이유가 있다는 것입니다. 프레임워크가 비동기 코드를 기다리는 것이 합리적이라는 것을 잠시 의심하지 않습니다. 나는 그것을 하지 않거나 콜백을 전달(또는 콜백을 전달하지만 콜백에 콜백을 전달하지 않음)하지 않은 N개의 다른 라이브러리에서 정확한 문제가 있었습니다. 그러나 실제로 비동기 수명 주기 후크를 사용하는 것이 합리적입니까? 아니면 "하지 말아야 할" 작업을 시도한 결과에 대한 이유입니까?

즉, created 완료되지 않은 구성 요소를 unmount 하려고 하면 어떻게 됩니까? 와우, 여전히 기다리는 것은 좋지 않습니다. 또는 destroying 완료되지 않은 mounted , 나는 그 기능의 구현자를 부러워하지 않습니다.

B & C를 A에 연결하는 대신 코드를 A.js에 "로드 A"로 이동한 다음 A.js가 "B.data" 및 "C.data"를 업데이트하도록 하는 것이 정말 혼란스럽습니다. . 그렇게 하면 어떤 이유로든 A.data가 변경되면 다른 구성 요소가 위임을 시도하지 않고 자동으로 다시 렌더링됩니다.

그것은 복잡성이 증가하고 나쁜 습관입니다. 여기에 전체를 작성해 보겠습니다. 무슨 말인지 보겠습니다. 하지만 제게는 복잡성이 많이 증가했습니다.

한 구성 요소에서 다른 구성 요소로 제어합니다. 공유된 경우에도 여전히 데이터를 분리하여 구성 요소 A 에서 A를 렌더링합니다. 우리는 fetchData 및 hasInitialized 와 같은 메서드가 포함된 단일 클래스를 사용했으며, 후자는 약속이고 전자는 후자를 해결합니다.

이것은 이제 구성 요소를 너무 많이 결합하고 있습니다. 우리는 이것들이 A를 제외하고 다른 것 없이 작동하기를 원합니다.

구성 요소를 직접 연결하면 구성 요소를 재사용할 수 없고 vue가 올바르게 다시 렌더링할 수 없도록 하는 예기치 않은 종속성 트리가 생성됩니다.

사실 당신은 요점을 놓치고 있습니다. 이것들은 각각 다른 것에 영향을 미치지 않고 사용하고 유지할 수 있는 확장과 느슨하게 연결되어 있습니다. 사실 <component-x /> , v-if , vuex 이외의 부모 코드를 작성하지 않고도 아무 곳에서나 여러 번 삭제할 수 있습니다.

나는 시연하기 위해 A를 B와 C에 연결했습니다. 이것을 멋지게 분할하거나 몇 개의 구성 요소가 응답했는지 계산한 다음 특정 예상 수(이 경우 2)에 도달하면 계속할 수 있습니다. 예를 들면 다음과 같습니다.

 this.$root.$emit('thruster-mounted') // in B and C
// instead of 
 this.$root.$emit('thruster-1-mounted') // for B and 2 for C

// then count the responses and resolve once they are >= 2 in component A

어쨌든, 이것이 내가 구성 요소 종속성 처리라고 말한 이유입니다. 이것은 바람직하고 예상되지만 복잡할수록 더 혼란스러워지기 때문에 가능한 한 덜 복잡하게 수행되어야 합니다.

또는 전역 범위가 아니라 A, B, C의 부모에게 직접 이벤트를 emit 하고 부모가 B와 C를 렌더링할지 여부를 결정하도록 합니다.

나는 당신이 이런 말을 할 줄 알았지만 이것은 바람직하지 않습니다. 이러한 구성 요소는 다른 것에 의해 제어되어서는 안 되므로 주요 구성 요소는 자식이 하는 일에 덜 신경쓰고 독립적으로 유지되어야 한다고 강조했습니다. 앱의 아무 곳에나 배치할 수 있고 여전히 동일한 작업을 수행할 수 있기를 원합니다 . 당신이 거기에서 말하는 것을 하는 순간 모든 것이 어떻게 무너지는지 지켜보십시오. 그러나 나는 움찔하지 않고 말 그대로 DOM 트리의 아무 곳에나 구성 요소를 배치할 수 있으며 모든 것이 제대로 작동합니다. 나는 이것의 사본을 여러 개 가질 수 있으며 여전히 작동합니다. async ... await 라이프사이클 덕분입니다.

  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

이 경우 B와 C가 렌더링되기 전에 실제로 렌더링해야 하는 A에 대한 것은 무엇입니까?

우리는 각 구성 요소가 마운트되기 전에 고유한 작업을 수행하기를 원합니다. 그러나 모든 구성 요소는 다른 모든 구성 요소가 해당 작업을 완료한 경우에만 렌더링됩니다. 그것이 여기의 이야기입니다.
따라서 vuex 저장소 에서 생성할 실제 데이터는 말할 것도 없고 상태 관리와 v-if 행운을 빕니다. 구성 요소가 사용되는 곳마다 많은 중복 코드가 작성됩니다. A와 C만 다른 구성으로 호스팅하는 또 다른 구성 요소가 있다고 가정해 보겠습니다. 작동하려면 v-if , vuex 상태 관리를 작성해야 합니다. 문제가 보이나요? 설명하겠습니다:

  // component Z totally different from foo, so we can't make this a component for reuse
  <template>
    <a-component @rendered="showBandC = true" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

  // component Foo totally unique, probably has other things it does
  <template>
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
// ok you could mixin this, fair, but complex nevertheless
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

..... 등등

다음과 같이 부모에서 아무 것도하지 않고 구성 요소를 사용하는 대신 :

  // component Z
  <template>
    <a-component />
    <b-component />
  </template>

  // component Foo
  <template>
    <b-component  />
    <c-component />
  </template>

... 기타 등등

created() 메소드에 항목이 있는 경우 JavaScript 클래스를 통해 또는 store 모듈을 사용하여 스토어를 채우는 것을 방해하는 것은 없습니다. 그러나 명시적 사용 사례가 더 도움이 됩니다. 즉, 캡처할 수 없는 사용자 스토리의 UX는 무엇입니까?

도처에 흩어져 있는 상태 관리에 대해 내가 말한 것을 기억하십니까? 우리는 이러한 구성 요소를 관리하는 것이 다른 곳에서 많은 것을 관리하게 된다는 것을 의미하는 것을 원하지 않습니다. 이는 제가 방금 수행한 작업 대신 매우 복잡합니다. 게다가, 내가 원하는 대로 되지 않습니다. 각 구성 요소가 매우 적은 복잡성으로 수행해야 하는 작업을 완료한 경우에만 마운트합니다.

아이디어는 Vue가 다음 후크 기능으로 이동하기 전에 내부적으로 비동기를 존중하는 것입니다.

물론 그 부분은 이해가 되지만 예제가 복잡해야 하는 이유를 잘 모르겠습니다. 다음과 같은 사용자 스토리를 말해보세요.

내 구성 요소에는 async beforeMount 및 async mounted 가 모두 있지만 beforeMount 의 코드가 완료되기 전에 mounted 의 코드가 실행됩니다. beforeMount 가 완료되기 전에 mounted 되는 것을 어떻게 차단할 수 있습니까?

요점은 이러한 구성 요소가 구성 요소 외부에 너무 많은 입력 없이 렌더링되고 사용되기 전에 일이 일어나기를 원한다는 것입니다. 이것은 우리가 만들고 있는 앱이 사용 가능했다면 더 잘할 수 있었을 것이라는 사실을 깨달았습니다. 나는 많은 mixin, vuex 및 모든 곳에서 (mixin 사용) 강하게 결합 된 부모가있는 코드를 작성하여 구성 요소가 누락되어 사용되었습니다. 이것은 복잡한 이야기가 아니라 실제로 일어난 일을 간단하게 말씀드리는 것입니다. 우리는 UI가 어떻게 설계되고 유지되어야 하는지 다시 생각해야 했습니다. 시각적으로 덜 흥미롭고 코드적으로 훨씬 복잡해졌습니다.

이 간단한 설정에 도입한 복잡한 사항이 수명 주기의 async ... await 기능으로 해결된 것이 얼마나 많은지 알 수 있습니까?

@wparad

즉, 생성이 완료되지 않은 구성 요소를 마운트 해제하려고 시도하면 어떻게 되는지, 와우, 여전히 기다리는 것은 좋지 않습니다. 또는 마운트가 완료되지 않은 것을 파괴하는 것, 나는 그 기능의 구현자를 부러워하지 않습니다.

여기 위치:

... 달성하려면 아키텍처에 대한 근본적인 재검토/재작성이 필요하며 수명 주기 후크의 동기적 특성에 의존하는 많은 논리를 잠재적으로 깨뜨릴 수 있습니다...

... 당신이 언급한 부분이라고 생각합니다. 우리는 이러한 극단적인 경우를 처리할 방법이 필요하며 아마도 이것이 도입하는 것 이상일 것입니다. 즉, 우리의 의도는 앱 충돌 없이 작동해야 합니다.

이러한 모든 경우에 실패할 수 있는 대부분의 비동기 작업과 마찬가지로 시간 초과를 사용하여 대기를 확인하거나 중단합니다.

그러나 제가 주의 깊게 제시한 예를 보면 무슨 말인지 알 수 있을 것입니다. 이것은 어디에서나 많은 코드를 작성하지 않고도 많은 것을 해결할 수 있었습니다. 사실 이것이 가능하다면 우리 앱은 훨씬 작고 조각 모음되고 이해하기 쉬운 코드베이스로 훨씬 더 나았을 것입니다.
이러한 종류의 기능에 대한 점은 장애물에 부딪힌 후에만 그 중요성을 볼 수 있다는 것입니다. 방금 제가 제공한 바로 이 예제에 대해 많은 해결 방법을 생각했을 때 이 페이지를 처음 방문했습니다. 나는 도움을 구하러 온 것이 아니라 Vue에서 사용할 수 없다는 것을 알았기 때문에 기능 요청을 제출하기 위해서였습니다.