Natalia Tepluhina와 함께하는 스매싱 팟캐스트 에피소드 26: Vue 3.0의 새로운 기능은 무엇입니까?

이 팟캐스트 에피소드에서는 VueJS에 대해 모두 이야기합니다. 3.0 릴리스의 새로운 기능은 무엇이며 마이그레이션이 얼마나 어렵습니까? Drew McLellan은 핵심 팀원인 Natalia Tepluhina와 이야기를 나누었습니다.

메모 표시

• 뷰JS
• Vue 3 마이그레이션 가이드
• 트위터의 나탈리아
• Natalia의 개인 웹사이트

주간 업데이트

• 디지털 제품 페이지를 디자인하는 다양한 방법
  저자 수잔 스카카
• React 네이티브 애플리케이션의 단위 테스트
  작성자 Fortune Ikechi
• Google Analytics가 UI/UX 디자인에서 웹 개발자를 돕는 5가지 방법
  클라라 부엔콘세호가 쓴
• TypeScript 제네릭 이해
  저자 제이미 코크힐
• 타이포그래피와 상호 작용하기 위해 얼굴 모션을 사용하는 방법
  Edoardo Cavazza가 각본을 맡은 작품

성적 증명서

Drew McLellan: 그녀는 열정적인 웹 개발자이자 Google 개발자 전문가이자 회의 연사이자 저자입니다. 현재 그녀는 GitLab의 스태프 프론트 엔지니어이지만 Vue JS 핵심 팀원으로 가장 잘 알고 있을 것입니다. 그래서 그녀는 거의 누구보다 Vue에 대해 잘 알고 있습니다. 그러나 그녀가 한때 캥거루에게 노래를 가르친 적이 있다는 것을 알고 계셨습니까? 내 Smashing 친구, Natalia Tepluhina를 환영하십시오.

드류: 나탈리아, 안녕하십니까?

Natalia Tepluhina: 안녕 Drew, 이것은 내 성에 대한 정말 멋진 시도였습니다. 나는 당신에게 크레딧을 제공해야합니다. 그것은 내가 영어 사용자가 내 성을 발음하려고 할 때 들었던 가장 좋은 말 중 하나였습니다. 러시아어를 못한다면 불가능할 것 같습니다. 정확한 발음은 Tepluhina이지만, 그래서 저는 보통 사람들에게 저를 Natalia라고 불러달라고 요청하는 것 같습니다.

드류: 알겠습니다. 노력했습니다. 그러나 중요한 질문은 스매싱을 하고 있습니까?

나탈리아: 물론이죠.

드류: 좋습니다. 그래서 저는 오늘 9월에 Vue 3.0이 출시되면서 정말 흥미로운 소식에 대해 이야기하고 싶었습니다. 버전 번호 면에서는 주요 릴리스였지만 실제로 Vue에 대한 큰 릴리스이며 꽤 오랫동안 작업 중이었습니다. 시간이 안 되었습니까?

나탈리아: 그렇지 . 2018년에 버전 3을 처음 발표한 것 같아요. 봄에 발표된 것 같아요. 실제 작업은 2018년 봄에 시작했고, 실제 작업은 2018년 가을에 시작했습니다. 그리고 2018년 10월에 있었던 런던 컨퍼런스에서 공식적으로 발표한 것 같아요. 활동 기간은 2년이 걸렸습니다. 그리고 생각해보면 2016년에 이전 버전이 출시되었습니다. 따라서 이 4년 중 절반도 Vue 3 작업에 전념했습니다.

Drew: 새로운 메이저 버전이 필요하다고 결정한 동기 요인은 무엇이었습니까? 메이저 버전으로 작업할 것인지, Vue 3에서 작업할 것인지, 아니면 단순히 버전을 올려야 하는 변경 사항이 누적된 것 같은 일종의 의식적인 결정이었습니까?

Natalia: 아니요, 몇 가지 매우 중요한 사항 때문에 새 버전을 만드는 것이 아이디어라고 생각합니다. 그래서 우선 반응성을 바꾸게 된 동기가 있었다. 이전 것은 Object.defineProperty를 기반으로 구축되었습니다. 그리고 몇 가지 주의 사항이 있었습니다. 모두 문서화되었지만 여전히 그렇습니다. 사람들이 해서는 안 되는 일을 문서화하더라도 어쨌든 할 것입니다. 그리고 당신은 그들에게 문서를 지시해야 할 것입니다. 그런데 아무도 문서를 읽지 않습니다. 어떤 이유로 그냥 발생합니다. 사람들이 지적할 때까지는 문서에 존재하지 않습니다. 하지만 좋아. 어쨌든 가르쳐드리겠습니다. 그래서 반응성이 그 중 하나였습니다.

Natalia: 성능은 그 다음이었습니다. Vue 2는 여전히 최악의 성능을 가졌거나 없었지만 Vue를 더 빠르게 만드는 방법에 대한 몇 가지 아이디어가 있었습니다. 또한 Vue를 사용하는 청중, 즉 청중의 특정 부분에 대한 한 가지 문제점이 있었습니다. 타입스크립트였습니다. Vue 2는 내부적으로 여전히 강력한 유형의 Flow로 작성되었지만 TypeScript로 입력하는 것은 특히 상태 관리 Vuex로 작업하는 경우 정말 악몽이었습니다. 이것은 다시 큰 부분이었습니다. 마지막은 구성 요소가 아니라 구성 가능한 논리 부분의 관점에서 논리를 추상화하는 기능을 놓쳤습니다. 기능 도우미 등과 비슷하지만 뷰어 활동도 포함할 수 있어야 합니다. 여기에서 좋은 예는 React Hooks가 될 수 있습니다. 바로 그것들을 통해 기능의 일부를 추상화할 수 있고 이것은 Vue에서 분명히 누락되었습니다. 그리고 지금은 "당신은 React에서 기능을 훔쳤습니다."라고 말하는 것처럼 들립니다. 사실은 아닙니다. 아이디어 교차 수분은 우리 생태계에서 크고 좋은 부분이며 개발자가 즐겨찾기 간에 전환하는 데 도움이 된다고 생각합니다. 그렇죠?

Natalia: 그래서 우리는 Vue 3를 메이저 버전으로 만들기 위해 이러한 주요 기능에 대해 작업하고 있었습니다.

Drew: 이제 오픈 소스 생태계에 존재하는 것의 가장 큰 장점 중 하나는 모든 종류의 다양한 프로젝트에서 얻은 풍부한 아이디어와 경험이 있으며, 이러한 아이디어를 다른 프로젝트에서 빌려오고 경험을 빌릴 수 있다는 것입니다. 프로젝트는 정말 유익하고 모든 것을 더 강력하게 만듭니다. 그렇죠?

나탈리아: 그렇지 . 제 생각에는 GitLab에서 반복 값을 호출하는 방식으로 작동합니다. 아이디어가 떠오르면 결코 완벽하지 않습니다. 그것은 대부분 매우 원시적이고 매우 하드 코딩된 것과 같습니다. 무언가를 바꿀 수도 있지만 확실히 완벽하지는 않습니다. 그리고 이 아이디어가 완벽하지도 않고 딱 좋도록 하려면 이 아이디어를 몇 번 반복해야 합니다. 그리고 생태계의 아이디어와 함께 발생합니다. 누군가 좋은 아이디어를 생각해 냈고, 당신은 그것을 받아들이고 더 좋게 만들었습니다. 그리고 나는 Vue에서 아이디어를 가져오는 무언가가 있을 것이라고 장담합니다. 아마도 그들은 이미 Vue에서 아이디어를 가져와 더 좋게 만들 것이며 여기에는 나쁠 것이 없습니다.

Natalia: 저는 "당신은 아이디어를 훔치고 있습니다"와 같이 강력히 반대합니다. 이것은 도둑질이 아니라 단지 교차 수분입니다.

드류: 맞아요. TypeScript로의 마이그레이션을 언급했기 때문에 Vue 3 자체는 현재 TypeScript를 사용하여 작성되었습니다. 맞나요?

나탈리아: 네, 그렇습니다. 그리고 저를 믿으세요, Drew. 저는 Vue를 TypeScript와 함께 사용하는 방법에 대한 작은 문서를 작성하고 있었습니다. 그리고 저는 아마도 Vue 2와 비슷할 것 같았습니다. 그리고 문서를 너무 복잡하게 만들어서 모든 것을 명시적으로 입력하는 것과 같았습니다. 모든 것이 잘 입력된 것 같습니다. 나는 유형을 볼 수 있으므로 내 t-link는 행복합니다. 지금까지는 너무 좋습니다. 그리고 TypeScript로 작업하던 개발자 중 한 명이 "이 작업을 수행할 필요가 없습니다."라고 말했습니다. 어떻게, 어떻게? “데이터에 명시적 유형을 수행할 필요가 없습니다. 초기 값을 지정하기만 하면 ts-link가 해당 번호를 알 수 있습니다. 이미 입력되어 있습니다.” 어때요? “문서에서 명시적 유형의 90%를 제거했습니다. 실제로 입력해야 하는 것은 구성 요소의 프록시이며 계산된 속성에는 두 가지가 있습니다. 여전히 반환 유형이 필요합니다. 그러나 나머지는 자동으로 입력되는 것과 같습니다. 우리가 구성 요소를 정의하는 메서드를 사용하여 구성 요소를 작성하면 됩니다. 그리고 그게 다야. 입력되어 있습니다.”

Natalia: 그것은 마치 작동하는 것 같았습니다. 그리고 저와 저는 과거 경험에서 Angular와 함께 일하고 있었는데 TypeScript에 스톡홀름 증후군이 있습니다. 모든 것은 명시적으로 입력해야 합니다. 복잡한 유형이 있는 경우 물론 인터페이스를 작성해야 하지만 이것이 TypeScript가 작동하는 방식입니다. 그래도 Vue 3를 사용하면 지금 TypeScript로 작업하는 것이 훨씬 쉽습니다.

Drew: 정말 좋습니다. Vue Core 프로젝트와 Vue를 사용하여 애플리케이션을 빌드하는 개발자 모두에게 이익이 됩니다. 이제 Vue에서는 TypeScript를 잘 사용할 수 있기 때문입니다. 2.0의 너무 쉽게. Vue 커뮤니티에 익숙한 사람들은 Vue의 제작자 Evan You가 여전히 프로젝트를 매우 적극적으로 이끌고 있음을 알 것입니다. 핵심 팀은 어떻게 작동합니까? 개발 프로세스와 관련하여 어떻게 구성되어 있습니까? 에반이 전부가 아니잖아요?

Natalia: 정말 좋은 질문입니다. Drew는 수년 동안 말 그대로 사람들이 Vue에 대해 다음과 같이 이야기했습니다. 이 말을 인용하면 거칠게 들릴 수 있지만 죄송합니다. . 그리고 Vue 1.X에도 이미 팀이 있었고 Vue 2 뒤에는 더 큰 팀이 있었고 Vue 3에는 더 큰 팀이 있었습니다. 문제는 Vue에 대해 말할 때 우리 모두는 다른 책임이 있다는 것입니다.

Natalia: Core에서 작업하는 사람들이 있습니다. 이 사람은 Evan 자신뿐만 아니라 Vue Core에서 대부분의 작업을 수행하고 있으며 확실히 프로젝트를 주도하고 있습니다. 그러나 Vue Core에서 일하는 사람들이 있으며 그들의 기여는 절대적으로 귀중합니다. 그리고 Vue 팀에 합류하여 Core에서 일하는 몇 명의 새로운 사람들이 있습니다. 그리고 에코시스템에서 작업하는 소규모 팀도 있고 Eduardo와 같이 Pure Router에서 작업하는 사람들이 있으며 Vuex에서 Vue CLI로 문서 작업을 하는 사람들도 있습니다.

Natalia: 문서화가 중요하다고 생각하기 때문에 문서화 작업을 하는 전체 팀이 있습니다. 그리고 현재 우리 웹사이트에는 Core 팀에 속한 21명, 20명 또는 21명이 항상 카운트를 놓치고 있다고 생각하지만 이것은 고정된 목록이 아닙니다. 우리는 분명히 고용하지 않고 오픈 소스 팀이기 때문에 이것은 급여를 받는 직업이 아닙니다. 그러나 누군가가 Vue 생태계의 일부에 많은 기여를 한다면, 사람들이 이미 Core 팀 구성원의 일을 하고 있을 때 저장소와 공식적인 직함에 대한 액세스 권한으로 인정을 받는 것입니다.

Drew: 오픈 소스 프로젝트에 기여하는 것이 실제로 개인에게 일종의 보상을 줄 수 있는 경우이기 때문에 좋습니다. 그들은 어느 정도 인정을 받고 그것은 당신의 전문 경력과 당신이 가진 것에 영향을 미칠 수 있습니다.

Drew: Vue에 익숙하지 않을 수 있지만 React, Angular 등과 같은 다른 반응 프레임워크에는 익숙할 수 있습니다. Vue 3의 큰 헤드라인 변경 사항은 무엇이며 구체적으로 어떤 문제를 해결하려고 합니까? 이전에 구성을 그 중 하나로 언급했는데, 그게 큰 변화인가요?

Natalia: 예, 이것은 가장 큰 변경 사항 중 하나이며 실제로 여기에서 분명히 말씀드리겠습니다. 컴포지션 API는 순전히 부가적입니다. 구성 요소를 다시 작성해야 하는 것이 아니라 TypeScript를 추가할 수 있습니다. 또는 모든 구문을 사용하는 것을 선호할 수도 있습니다. 이제 이를 옵션 API라고 하며 이 용어에서는 아무 것도 변경되지 않습니다. 우리가 새로운 API에 대해 말할 때 이것은 브레이킹 체인지가 아닙니다. 저는 이것을 정말 강조하고 싶습니다. 처음으로 Composition API를 발표했을 때 정말 끔찍한 순간이었습니다.

Natalia: 변경 사항을 잘 설명하지 않은 것 같아서 표준 빌드가 Composition API인 것처럼 보이게 만들었습니다. 그것은 완전히 우리의 잘못이며 옵션은 아마도 Vue 3가 아닌 향후 빌드에서 더 이상 사용되지 않을 것입니다. 그리고 사람들이 당신이 말한 것을 잘못 읽을 가능성이 있다면 그들은 그것을 잘못 읽을 것입니다.

Natalia: 이 진술 직후에 RFC에서 변경을 제안했고 Reddit은 폭발했습니다. Reddit은 "맙소사. 다 써야겠습니다. 세상에. Vue는 새로운 Angular입니다. 그들은 모든 것을 부숴버릴 것입니다.” 그리고 dev.to에 Vue's Darkest Day라는 기사를 만든 사람이 있었습니다. 솔직히 가장 어두운 날이었다. 우리는 그렇게 느꼈지만 나는 내 자신의 Twitter에서 "우리가 정말로 ... 그들은 우리가 RFC를 변경하기 시작했다고 말하고 Evan은 변경 사항을 발표하지 않고 RFC를 변경하기 시작했다고 생각합니다. 그래서 그는 "이거 빨리 다시 쓰겠습니다. 마치 마스터로 밀어넣자." 사람들은 이에 대해 화를 냈습니다. 그들이 특정 요점에 대해 논쟁하고 있었기 때문에 페이지를 새로 고치기만 하면 해당 요점이 더 이상 존재하지 않습니다. 당신은 기분이, 내가 바보인가 아니면 그냥... 도대체? 즉, 바로 거기에 있었다. 나 이거 기억해. 그리고 저는 우리의 커뮤니케이션 전략이 더 나을 수 있다고 믿습니다. 이것은 우리가 아닙니다.

Natalia: 지금 제가 구성에 대해 말할 때마다 이것은 순전히 부가적인 것입니다. 이것은 단지 좋은 기능입니다. 당신은 그것을 사용할 수 있습니다, 당신은 그것을 사용할 수 없습니다, 당신은 의무가 없습니다. 그냥… 존재합니다.

Drew: 누군가가 그 문제를 해결하는 데 도움이 되는 새로운 것인 Composition API에 대해 어떤 종류의 문제가 있습니까? 어떤 문제를 해결하고 있습니까?

Natalia: 내부에 몇 가지 기능이 있는 구성 요소를 상상해 보십시오. 검색 및 정렬이라고 가정해 보겠습니다. 특정 목록을 검색하고 정렬하려고 한다고 가정해 보겠습니다. 이것은 이미 두 가지 다른 기능이며 Vue 구성 요소의 문제는 논리가 아닌 옵션을 기반으로 분할된다는 것입니다. 검색 및 결과 배열에 대한 쿼리를 만들어야 하기 때문에 검색에 쿼리가 있다고 상상해 보세요. 그리고 이것들은 두 가지 반응성 속성입니다. 구성 요소 측면에서 데이터라는 옵션에 배치합니다. 그리고 분명히 정렬을 수행하려면 몇 가지 방법이 필요합니다. 버튼 클릭일 수도 있고, 검색을 실행하는 다른 것일 수도 있습니다. 메소드를 생성합니다. 그리고 정렬을 위해서는 정렬 옵션에 따라 또 다른 반응 속성을 구축해야 합니다. 그런 다음 결과를 정렬하기 위해 몇 가지 계산을 수행합니다.

Natalia: Vue에서는 이를 위해 또 다른 옵션인 계산된 속성도 있습니다. 결국 구성 요소가 실제로 조각화되었습니다. 그리고 내가 개발자이고 검색 부분에서만 작업해야 하는 작업이 있다고 상상해 보세요. 지금은 구성 요소를 분할할 수 없습니다. 이 두 기능이 교차하는 방식이기 때문입니다. 일부 결과를 검색하고 정렬합니다. 그리고 데이터에서 메서드로, 메서드에서 계산으로 이동해야 하며 결국 컨텍스트를 전환하는 것은 정말 어렵습니다. 특히 구성 요소가 정말 커지면 더욱 그렇습니다.

Natalia: Vue 2.0에는 어떤 옵션이 있었나요? 첫 번째 옵션은 믹스인(mixin)이라고 했으며 믹스인은 컴포넌트가 가질 수 있는 동일한 속성을 포함할 수 있는 객체일 뿐이며 컴포넌트와 혼합하고 있습니다. 좋은 것 같습니다. 모든 검색을 거기로 이동할 수 있습니다. 문제는 무엇입니까? 몇 가지 있습니다. 첫째, 이것은 완전히 유연하지 않습니다. 특정 종점을 찾고자 하고 이것을 믹스인으로 옮기면, 이것이 내가 검색할 수 있는 유일한 종점일 것입니다. 믹스인은 매개변수를 허용하지 않습니다. 믹스인을 만들었는데 완전히 정적입니다. 두 번째 문제는 mixin이 혼합되어 특정 속성에 대해 병합처럼 발생한다는 의미입니다. 예를 들어 후크를 만든 경우 병합됩니다. mixin 구성 요소의 수명 주기 후크에 있는 모든 논리가 함께 병합됩니다. 그러나 데이터 속성, 믹스인에 콜드 쿼리가 있고 구성 요소에 동일한 속성이 있는 경우 구성 요소에 우선 순위가 있습니다. 재정의됩니다. 경고가 표시되지 않습니다. 전적으로. 그것은 그냥 일어날 것이고 당신은 이것이 일어났는지 모를 것입니다.

Drew: 모든 스코프가 완전히 혼합되어 있습니까?

나탈리아: 네, 완전히. 당신이 볼 기회가 없으며 또한 믹스인은 출처가 매우 불분명합니다. 이름이 있는 믹스인을 가져와서 컴포넌트 속성 믹스인을 보기 위해 넣으면 됩니다. 그것은 매우 암묵적이며 내 자신의 경험의 관점에서 이것에 대해 말하고 있습니다. GitLab에는 구성 요소에 2개의 믹스인이 포함되어 있고 이 두 믹스인에 각각 다른 믹스인이 포함되어 있는 논리가 있습니다. 여기에서 확인해야 할 속성이 있으며 구성 요소에 없습니다. 더 깊이 들어가 봅시다. 첫 번째 레벨 믹스인입니다. 이것도 들어있지 않고 이것도 들어있지 않습니다. 곳은? 당신은 이 속성을 찾기 위해 토끼굴 아래로 더 깊이 잠수하고 있으며 테스트도 악몽이 됩니다.

Natalia: Mixin은 논리를 추출하는 매우 멍청한 방법입니다. 단순하고 분명하며 매우 쉽게 얻을 수 있습니다. 고급 수준에서 이 작업을 수행하려는 경우 많은 문제가 발생합니다. Vue 2.0에서 논리를 추상화하는 다음 방법은 렌더리스 구성 요소였습니다. Vue에서 컴포넌트는 슬롯을 포함할 수 있습니다. 기본적으로 상위 구성 요소에서 무엇이든 넣을 수 있는 부분입니다. 작은 창, 실제로 슬롯. 그리고 범위가 지정된 슬롯에 대한 아이디어가 있습니다. 자신의 범위를 부모에게 다시 노출할 수 있는 자식 구성 요소와 슬롯 콘텐츠가 이에 액세스할 수 있다고 상상해 보십시오. 슬롯이 있는 구성 요소가 있고 구성 요소가 검색과 관련된 모든 논리를 수행한다고 상상해 보십시오. 과거 매개변수가 있는 끝점이 있는 검색을 가정해 보겠습니다. 검색과 같은 우리의 자식 구성 요소는 범위의 이 부분을 다시 부모에게 노출합니다. 검색결과입니다. 즐기다. 잘 들린다. 확실히 믹스인보다 좋은 소리가 납니다. 매개변수를 테스트할 수 있습니다. 논리는 여기에 명시되어 있습니다. 우리는 무언가를 반환합니다. 문제? 몇 가지 있습니다.

Natalia: 먼저 구성 요소 인스턴스를 만들었습니다. 이것은 세계에서 가장 저렴한 수술이 아닙니다. 두 번째 부분은 런타임입니다. 구성 요소는 런타임에만 작동하며 이 구성 요소의 노출된 속성은 슬롯 범위로 노출한 슬롯에서만 사용할 수 있으므로 검색 결과는 템플릿의 작은 부분에서만 사용할 수 있습니다. 구성 요소의 개별 부분을 가지고 놀고 싶다면 거기에 접근할 수 없습니다. 런타임입니다. 다른 곳에서 반응 상태가 필요한 경우 이 논리에 대한 조치가 없었습니다. 물론 순수 함수와 같은 도우미를 만들어 결과를 반환할 수도 있지만 반응 속성에 대해 작업해야 하는 경우에는 어떻게 해야 할까요? 그렇게 해서 합성 API가 만들어졌습니다. 컴포지션 API를 사용하면 독립형 반응 상태를 가질 수 있습니다. 반응 상태는 더 이상 구성 요소의 일부가 아닙니다. 어떤 객체나 기본형을 반응형으로 만들 수 있습니다. 그리고 그것을 부모에게 다시 노출할 수 있습니다. 매우 명시적입니다.

Natalia: 부모에게 반환하려는 모든 속성이 노출됩니다. 명시적입니다. 이것을 클릭하면 어디에 있는지, 무엇인지 등을 볼 수 있습니다. 그리고 가장 좋은 점은 데이터 메서드, 컴퓨터 속성 등이 있는 오래된 좋은 구성 요소에 Composition API의 일부를 포함하면 바로 작동한다는 것입니다. 완벽하게 작동합니다. 구성 요소에 몇 가지 반응 속성과 메서드를 추가하기만 하면 이전 옵션 API와 함께 사용할 수도 있습니다.

Drew: 이것은 매우 복잡한 구성 요소나 심지어 약간 복잡한 구성 요소 조합과 관련하여 개발자가 코드 기반을 정리하는 데 정말 도움이 될 것 같습니다. 그리고 믹스인과 사물의 테스트 가능성에 대해 언급했는데, 컴포지션 API가 더 나은 테스트 가능성을 허용하나요?

Natalia: 예, 확실히 구성 API 때문입니다. 여기서 수명 주기 후크를 제외하면 구성 가능 항목에서 다른 수명 주기 후크를 실행할 수도 있기 때문입니다. 실제로 순수한 기능입니다. S-파라미터가 있고 무언가를 하고 있으며 수명 주기 후크 외부에는 여전히 부작용이 있습니다. 그리고 아시다시피 순수 함수를 테스트하는 것이 가장 쉬운 방법일 것입니다. 그것은 단지 블랙박스이고, S-파라미터가 있고, 반환할 것이 있습니다.

Drew: Vue로 더 복잡한 앱을 구축하는 많은 사람들이 높이 평가할 것으로 확신하는 문제에 대한 매우 포괄적인 솔루션처럼 들립니다. 그리고 그것은 확실히 내가 아는 믹스인에 끼어들 수 있는 종류의 버그를 제거하는 정말 좋은 방법처럼 들립니다. 여기서 언급한 것처럼 범위가 병합되고 모든 종류의 것들과 함께 버그를 도입하는 것이 매우 쉽습니다.

Drew: 저는 프레임워크를 기반으로 빌드를 선택할 때 항상 시간 경과에 따른 API 안정성을 크게 고려합니다. 아마도 안정성이 올바른 단어가 아닐 수도 있지만, 제 생각에는 우리 중 많은 사람들이 프레임워크를 기반으로 구축하는 데 어려움을 겪었고, 큰 재작업을 거쳐 마이그레이션에 막대한 투자가 필요하거나 결국 구속되는 앱을 남겼습니다. 더 이상 지원되지 않는 이전 버전의 프레임워크로 이동합니다. 끔찍한 상황입니다. Vue 2에서 Vue 3으로 큰 프로젝트를 옮기는 데 얼마나 많은 시간을 할애해야 할까요?

Natalia: 우선 API 표면이 이전과 90% 동일합니다. 더 이상 사용되지 않는 이벤트 허브로 교체할 수 있는 사용되지 않는 항목이나 사용되지 않는 필터가 많지 않았습니다. EventEmitter를 사용하려면 뷰 기반 뷰도 일부 외부 라이브러리로 교체해야 합니다. 이것들은 큰 변화지만 마이그레이션에 대해 이야기하자면… 분명히 말하겠습니다. 저는 지금 Vue JS Core Team 멤버이기 때문에 지금 정말 괴로워합니다. 반면에 저는 Vue를 사용하는 큰 프로젝트의 스태프 엔지니어입니다. 지금 마이그레이션을 시작하려는 경우 그렇게 하지 않는 것이 좋습니다. 우선 생태계가 출시되지 않았습니다. 즉, Pure Router, PUX, Vue CLI와 같은 핵심 라이브러리에 대해 말하면 이들은 양호한 상태이지만 여전히 릴리스가 아니라 릴리스 후보입니다. 그리고 핵심 라이브러리가 아닌 다른 생태계에 대해 이야기한다면 UI 구성 요소 라이브러리, 일부 양식 유효성 검사 라이브러리는 대부분 Vue 3에 대해 준비되지 않았습니다. 그리고 큰 프로젝트가 있는 경우 필요한 종속성이 너무 많습니다. 케어. 그래서 이것은 복잡한 일이 될 것입니다.

나탈리아: 옵션이 무엇입니까? 큰 프로젝트가 있고 이 모든 구성 API 장점을 사용하려고 합니다. 이것을 달성하는 방법? 먼저 Vue 2.0, Vue 2.7의 LTS 빌드를 출시할 계획입니다. 여기에는 많은 사용 중단 경고가 포함되므로 사용 중단될 항목, Vue 3으로 중단하지 않도록 리팩토링하는 방법을 볼 수 있습니다. 따라서 기술적으로 여전히 Vue 2를 사용하지만 Vue 3을 준비하게 됩니다. 어쨌든 모든 경고가 있기 때문입니다.

Natalia: 둘째, Vue 2와 관련된 것을 Vue 3 대안으로 대체하여 코드 모드로 작동할 수 있는 마이그레이션 도구를 사용할 것입니다. 물론 완벽한 코드 모드는 없습니다. 우리는 우선 가능한 한 교체하는 것을 목표로 하지만 사용 중단이 쉽게 처리되지 않을 때마다 경고도 표시합니다. Codemod는 사물을 인식하고 경고를 던질 수 있지만 자체적으로 대체할 수는 없습니다. 이것은 큰 계획과 같고 Vue 2.7이 출시되는 순간에 내 기억이 맞다면 예상 도착 시간은 12월인 것 같습니다. 로드맵을 확인해야 하지만 12월인 것 같습니다.

Natalia: 생태계도 어느 정도 준비가 되어 있을 것입니다. Vue 2.0이 포함된 대규모 프로젝트가 있는 경우 Core가 안정화될 때까지 조금만 더 기다리세요. 완벽한 라이브러리를 생성하더라도 사람들이 이것을 사용하기 시작하고 사람들이 버그를 보고하기 시작하기 때문에 안정화하는 데 여전히 시간이 필요하기 때문입니다. 애완 동물 프로젝트에 사용하고 버그를 보고하려는 경우 매우 환영합니다. 그리고 그 후에 Vue 3로 마이그레이션하는 좋은 방법이 있을 것입니다.

Drew: 말씀하신 마이그레이션 도구는 꽤 흥미롭게 들립니다. 기본적으로 코드를 살펴보고...

Natalia: 예, 예, 예, 그것은 코드 또는 도구입니다. 지금은 매우 제한된 방식으로 사용할 수 있습니다. Vue CLI의 플러그인으로 사용할 수 있습니다. Vue CLI 기반 프로젝트가 있는 경우 Vue 업그레이드를 실행하고 도구가 어떻게 작동하는지 확인할 수 있습니다. 지금까지 우리가 원하는 모양이 아닙니다. 불행히도 저는 Vue CLI를 기반으로 구축된 프로젝트에서 일하지 않습니다. 어떤 일이 진행되고 있는지 확인하고 기다려야 하지만 예를 들어 GitHub의 경우 더 이상 사용되지 않는 항목을 알고 있기 때문에 준비할 마이그레이션 도구 없이도 이미 몇 단계를 수행했습니다. 실제로 Vue 3 문서에 명시되어 있습니다.

Natalia: 마이그레이션 가이드가 있습니다. 모든 주요 변경 사항과 더 이상 사용되지 않는 항목을 볼 수 있으며 Vue 2.0 코드 기반에서도 이미 일부 작업을 수행할 수 있습니다. 예를 들어, Vue 2.6에서 우리는 슬롯의 구문을 변경했습니다. 범위 슬롯에 대한 구문은 더 이상 사용되지 않지만 거부되지는 않았으며 여전히 존재합니다. 경고가 표시되지만 실행할 수 있습니다. 그리고 물론 7년 된 코드베이스를 사용하여 작동만 하면 사용되지 않는 구문을 모두 교체하는 데 신경 쓰지 않습니다. 생산에 경고가 없습니다. 슬롯이 작동합니다. 개발 과정에서 "오, 콘솔에 경고가 표시됩니다. 아마 20개쯤 되겠죠. 빨간색이 아니라 노란색입니다. 난 상관 없어."

나탈리아: 누구에게나 일어나는 일이라는 걸 알잖아요. 우리는 이 작업을 위해 거대한 에픽을 만들었습니다. 이전 구문의 현재 집합을 모두 찾습니다. 우리는 EventEmitter를 교체하기 위해 노력합니다. 다시 7년 된 프로젝트입니다. 우리를 판단하지 마십시오. EventEmitter가 있습니다. GitLab은 EventHubs에서 작업 중이었습니다. Vue 기반 재미를 외부 라이브러리로 대체했습니다. 나는 똑같이하는 것이 좋습니다. 마이그레이션 가이드를 통해 이미 교체할 수 있는 항목과 이를 준비하고 작업을 시작하기 위해 이미 수행할 수 있는 변경 사항을 확인하십시오.

Drew: 마이그레이션 도구의 현재 상태는 코드베이스로 물을 테스트하는 좋은 방법입니다. 그것을 실행하고 이미 플래그가 표시된 것을 살펴보고 괜찮아 보이는지 또는 큰 것이 있는지 또는 아직 미성숙한지 확인하십시오. 실제로 문제를 해결할 수 있는 12월까지 기다리는 것이 더 낫습니까?

Natalia: 큰 프로젝트가 있었다면 그렇게 하지 않는 것이 좋습니다. 작고 나쁜 프로젝트나 개인 프로젝트가 있지만 그렇게 크지 않은 경우 두 개의 중간 규모 프로젝트에서 실행하고 있기 때문에 실행하고 있는 것과 같은 문제를 확인하는 것이 좋습니다. 한두 가지 문제라고 생각합니다. 미성숙하다고 할 수는 없다. 이미 좋은 상태입니다. 그러나 다시 큰 프로젝트의 경우에는 유산이며 이국적인 것들입니다. 프로덕션에서 이러지 마세요.

Natalia: 또한 프로젝트의 스캐폴딩을 가지고 놀고 싶다면 지금 Vue CLI는 두 가지 모드를 지원합니다. Vue 2 프로젝트를 생성할 수 있고 Vue 3 프로젝트를 생성할 수 있습니다. 그리고 적어도 한 번 시도해 보십시오. 이것은 플레이하면서 버그를 발견하고 버그를 보고하고 수정하려고 노력하기 때문에 우리에게도 좋은 방법입니다.

Drew: 문서와 개발 로드맵에서 마이그레이션 빌드에 대한 언급을 보았습니다. 그것은 우리가 이야기한 것과 다른 것입니까, 아니면 우리가 이야기하고 있는 것입니까?

나탈리아: 아니요, 똑같습니다. 동일하고 준비가 되어있어야 하지만 지금은 마이그레이션을 계획하는 경우 기본 경로는 문서를 읽고 거기에 있는 말을 따르는 것입니다. 마이그레이션 도구가 없을 때마다 우리는 확실히 노력하기 때문에 문서 팀이 계속 진행하기 때문입니다. 변경 사항, 변경된 이유 및 실제로 대체되는 사항에 대한 자세한 가이드를 작성했습니다.

Drew: 예, 문서에는 Vue 3 문서의 일부로 상당히 포괄적인 마이그레이션 가이드가 있으며 마이그레이션이 필요한 변경 사항이 엄청나게 많이 언급되어 있습니다. 나는 그 중 일부가 모든 프로젝트에 영향을 미치지 않을 것이라고 생각합니다. 그들 중 많은 사람들이 본질적으로 많은 사람들에게 극단적인 경우였습니다. 공정한가요?

Natalia: 예, 예를 들어 필터와 같은 많은 부분은 확실히 일부 예외적인 경우입니다. GitLab에서도 세 번째로 7년 된 코드베이스와 큰 코드베이스가 있기 때문입니다. 필터가 한두 번 발생했으며 더 이상 사용되지 않았습니다. "아, 사용하지 않는 코드"와 같이, 누가 신경쓰는 코드가 존재하기 때문에 우리가 그것들을 검색하고 완전히 제거한 것은 좋은 일이었습니다.

Natalia: 완전히 획기적인 변경은 모델 변경이라고 말하고 싶습니다. 내가 아는 모든 단일 프로젝트에는 적어도 하나의 Vue 모델이 포함되어 있으므로 이것을 살펴보십시오. 현재 클래스와 스타일, 튜블러 및 에테르를 포함하고 있기 때문에 이것은 확인해야 하고 속성도 변경될 수 있습니다. Vue로 작업한 적이 있다면 이전에는 Vue가 포함되지 않았습니다. 지금은 클래스와 스타일을 자식 구성 요소에 전달하는 방식이 약간 다르며 확실히 주의할 가치가 있습니다.

드류: 다행이네요. Vue와 함께 출시되는 3.0 릴리스는 생태계와 그 주변의 모든 것, Vuex 및 해당 수준으로 나아가는 데 필요한 생태계의 다른 모든 부분을 언급했다는 의미입니다. 그렇기 때문에 현재 웹 사이트에서 큰 "시작하기" 버튼이 여전히 모두 Vue 2로 이동합니까? Vue 3가 출시된 것처럼 느껴지지만 완전한 확신은 아닙니다. 그런데 아직도 그런 생태계 문제 때문일까요?

Natalia: 아니요, 방금 버그를 찾은 것 같습니다. 빨리 확인하겠습니다. 아니요, 시작은 Vue 3을 가리키고 있습니다. 괜찮습니다. vuejs.org에 가면 버전 2를 가리킵니다. 이는 의도적으로 Vue 2와 같은 하위 도메인으로 대체할 계획이어서 작업이 진행 중이지만 지금까지는 vuejs.org를 그대로 두고 Vue 3을 만들기로 결정했기 때문에 vuejs에 배너가 있습니다. 조직 어떤 문서에 가보면-

Drew: 맨 위에 아주 작은 배너가 있습니다. 네.

나탈리아: 네, 작은 것 같아요.

드류: 네.

Natalia: 더 크게 만들어야 할 것 같아요. 더 크고 색상 대비가 더 좋습니다. 내 접근성 느낌은 "오, 거기에는 대조되는 것이 없습니다"처럼 유지됩니다.

드류: 좋은 소식이네요. 누군가가 시작한다면 큰 프로젝트는 아닐 수도 있지만 누군가가 개인 프로젝트를 시작하거나 Vue를 배우고 싶다면 Vue 3가 시작하는 곳이겠죠?

나탈리아: 그렇게 말하고 싶습니다. 그런데 학습 곡선은 그렇게 다르지 않습니다. 이전 구문 옵션을 사용하는 것이 문서 팀의 의도였기 때문에 이전 구문이라고 해서는 안 됩니다. 실제로는 현재 구문입니다. 익숙한 구문이 기본 구문입니다. Vue 3 문서를 살펴보면 고급 주제에서만 Composition API로 볼 수 있고 Vue 3을 사용하는 학습 경로는 Vue 2에서와 비슷하기 때문입니다. 새로운 것으로 시작하는 데 큰 문제는 없습니다. Vue를 배우고 실험해보고 경력에 대해 이야기한다면 더 나은 투자가 될 것이라고 생각합니다. 모든 프로젝트를 능가할 것이기 때문에 최신 버전을 배우기 시작하십시오. 결국에는 반년, 일년에 걸쳐 대규모 프로젝트의 경우에도 마이그레이션이 있을 것입니다.

Drew: 제 개인적인 경력에는 플랫폼이 대규모 마이그레이션 과정에 있는 것처럼 플랫폼에 올 수 있는 진정한 재능이 있는 것 같습니다. Macromedia Director가 그 정도로 거슬러 올라가서 Shockwave, Flash 및 모든 종류의 것들을 기억하십니까? 나는 그들이 점 구문으로 전환하고 있을 때 그 점을 알게 되었고 둘 다 배워야 했습니다. 그리고 여기 저는 지난 달에 Vue에서 처음으로 Vue 2 프로젝트에서 작업하고 Vue 3에서 제공될 모든 것을 기대하면서 배우며 배우고 있는 제 자신을 발견합니다. 마이그레이션할 때 무언가를 배우는 것은 확실히 흥미로운 시간이지만 Vue에서는 그다지 어렵지 않은 것처럼 들리고 생태계가 Core를 따라잡으면 좋은 위치에 있어야 합니다.

Natalia: 오, Drew, 당신이 대규모 프로젝트 이민에 대해 말한 것에 대해 요점을 말하고 싶습니다. 2018년과 내가 GitLab에 합류하는 모습을 상상할 수 있습니다. 나는 핵심 팀원이 아니었고 이 순간에 기여자일 뿐입니다.

Natalia: 즉시 Evan은 "오, 우리는 Vue 3를 만들 것입니다"라고 말했습니다. 모두가 "예, 멋지다"고 좋아합니다. 2019년 봄, 당신은 Core Team입니다. 내 말은 GitLab 전체가 "오, 이거 귀엽다. 우리 모두는 이주를 하고 있는데 누가 책임이 있는지 알고 있습니까?” 그리고 Vue 3에 대한 문서를 작성할 때 어떤 일이 일어나는지 상상할 수 있을 뿐입니다. 모두가 읽고 회사는 "오, Vue 3에 대해 뭔가를 배우고 싶은데 문서를 이해할 수 없습니다." 그래서 당신은 "아, 이건 너무 고통스럽습니다"라고 생각하는 것입니다. 왜냐하면 당신이 그곳의 개발자이자 일종의 기술 작가이기 때문입니다.

Natalia: 당신은 이것의 한가운데에 있지만, 프레임워크로 생성된 모든 큰 제품은 버그를 찾아 라이브러리로 다시 가져올 수 있는 훌륭하고 절대적으로 훌륭한 전장이기 때문에 프레임워크에도 정말 유익하다고 말해야 합니다. 생태계. 테스트라고 말할 수 있고 GitLab은 Vue용 테스트 도구인 Vue Test Utils라는 오픈 소스입니다. 한 팀이 테스트를 기반으로 하는 테스트 코드를 사용하고 있었습니다. 이는 매우 의미가 있습니다. 일부 극단적인 경우 등을 찾을 수 있기 때문입니다. 하지만 여전히 GitLab을 Vue 3로 마이그레이션하는 것에 대해 생각하면 이에 대한 개인적인 책임감이 느껴집니다. 저는 마이그레이션 중일 뿐만 아니라 발견할 모든 단일 버그에 대해 개인적으로 책임이 있습니다.

Drew: 이전 세대의 JavaScript 프레임워크를 돌이켜 보면 그 중 가장 성공적인 것 중 하나가 당시에 jQuery였으며 매우 잘 설계된 API를 가지고 있었기 때문에 인기를 얻었다고 생각합니다. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

드류: 정말이야.

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.