Flow vs Typescript Flow에서 Typescript까지.왜?

내 블로그에 최초 발표: https://sobolevn.me/2019/03/from-flow-to-typescript
이 모든 것은 약 2년 전에 시작되었다.나는 내 응용 프로그램에서 undefined is not a function과 같은 어리석은 자바스크립트 오류가 끊임없이 발생하는 것에 대해 메스꺼움을 느낀다.그래서 나는 선택할 수 있는 정적 유형을 추가하기로 결정했다.
2년 전,javascript 분야는 완전히 다르다.Flow과 TypeScript은 모두 많은 단점이 있다. 라이브러리 지원이 나쁘고 IDE 지원이 거의 없는 것부터 유형 문제와 제한이 없는 것까지.내가 Flow을 선택한 것은 단지 그것이 더욱 시작하기 쉽기 때문이다. .babelrc 에 삽입하여 작업을 시작합니다.
약 6개월 전, 나는 우리의 모든 전단 프로젝트를 Flow에서 TypeScript으로 이전하기로 결정했다.이것은 내 머릿속의 격전이다.그래서 나는 다른 사람들이 정확한 도구를 선택할 수 있도록 쓰기로 결정했다.내 실수를 범하지 마라.
이 도구들은 매우 비슷해서 일반javascript에 유형 안전성을 제공합니다.본고는 not about types 또는 구조와 명사 아형 간의 차이이다.그것은 이 도구들의 현재 상태를 더 많이 소개했다.
유형 때문에 입력 도구를 변경하는 경우는 거의 없습니다.

떠벌리다

나는 모든 기술 결정에서 가장 중요한 방면부터 시작할 것이다.네, 그것은 투기 구동에 관한 개발입니다.

그러지 마세요.나는 그것이 어떻게 일을 하는지 설명할 것이다. 아마도 너는 생각을 바꿀 것이다.
나는 자주 speak에 관한 글을 쓴다. 등등. 내가 Flow을 사용하고 있다고 말할 때마다 다른 개발자들은 나에게 "왜 TypeScript을 사용하지 않습니까?"라고 묻는다.매번 나는 나의 선택을 설명해야 한다.세부 사항, 역사와 도구를 깊이 이해하다.때로는 현재 프로젝트의 상태와 우리의 작업 절차를 설명하기도 한다.네가 어떤 일을 제창하지 않을 때, 이것은 유쾌한 경험이 아니다.나는 단지 사용자일 뿐이다.나는 결코 정말로 하나를 좋아하는 것이 아니라 다른 것을 좋아한다.한 번 또 한 번 이런 대화를 하는 것은 정말 이상하다.
그 밖에 우리는 우리의 고객과 we hire의 다른 개발상들에게 서비스를 제공한다.그들 중 일부는 확실히 TypeScript과 합작하고 싶지만, Flow과 합작하고 싶지 않다.왜?TypeScript을 들었기 때문에, 이것은 정말 대단하다.Flow 부근의 투기 열차는 그리 거대하지 않다.

Me: Hi, we use X, Y, Z, and Flow for this project

Dev: Flow? Why not TypeScript?

Me: Oh, are kidding me? 🤦

만약 당신이 이런 투기와 싸우고 싶지 않지만, 그것을 당신을 위해 봉사하게 하고 싶다면, 한쪽으로 물러나서 어떤 투기도 사용하는 것이 가장 좋다.현재 작업 흐름에 큰 변화가 없다는 것을 기억하십시오.

인프라

Vue 3.0 will support TypeScript 기존 Nuxt는 TypeScript을 지원합니다.원본 코드와 함께 형식을 발표하는 항목이 많습니다.axios, vuex, vue-router, lodash 등등.Flow 지원은 어떻습니까?Vue는 현재 Flow을 사용하여 입력 (3.0부터 TypeScript으로 전환) 하고 있지만, 이러한 유형은 개발에만 사용됩니다.너는 자신의 항목에서 그것들을 사용할 수 없다.
어쩌면 다른 유형이 있을지도 몰라요?예, Flow에는 자체 유형의 저장소가 있습니다.문제는 설치 유형이 완전히 새로운 추가 절차라는 것이다.postinstall 갈고리를 설정하여 매번 npm install이 호출된 후에도 유형의 기초를 다시 설정해야 합니다. (예, git rebase)flow-typed포를 깊이 연구했을 때, 주로 반응을 향한 것임을 발견할 수 있다.Flow 심지어 표준 라이브러리에는 React 원어가 많다.나는 매우 이상하다고 생각한다.
그런데 특정 Vue 유형에 대해서는요?네, 한 사람이 관리하는 @vue-flow-type package을 찾을 수 있습니다.슬프게도 나는 이 독신자다.나는 몇 개의 유행 프로젝트를 유지하는 유형에 정말 싫증이 났다.네가 상상한 바와 같이 오류, 유형 변경, 새로운 버전 등이 있다.TypeScript이 나를 위해 이 시합을 이겼다.그것의 분배 시스템은 나에게 별도의 일을 강요하지 않을 것이다.물건을 좀 설치하기만 하면 그것은 일을 할 수 있다.types/ 하위 폴더는 npm을 통해 원본 코드와 함께 제공되기 때문입니다.추가 절차가 필요 없습니다.라이브러리 작성자는 types/ 폴더를 코드 라이브러리의 나머지 부분과 함께 유지보수합니다.그들은 모든 것이 정상임을 확보할 수 있다.

집적 회로 설비

Flow 프로젝트에 대한 IDE의 지원을 살펴보겠습니다.아니면'IDE 지원 없음'이라고 말할게요.
이것은 무슨 큰일이 아니다. 나는 nano만 있으면 코드를 작성할 수 있다.그러나 나는 text editors에서 많은 시간을 보냈고, 나는 그들이 우호적으로 지내기를 바란다.유감스럽게도 모든 주요 IDE(및 텍스트 편집기)의 Flow 플러그인은 결함이 있고 신뢰할 수 없습니다.예를 들어 VSCode plugin은 전혀 작용하지 않는다.
또한 VSCode는 최고 수준의 TypeScript 지원으로 유명합니다.인텔리센스, 형식 검사, 실시간 자동 완성을 사용합니다.

우리의 VSCode + TS + Vue 설정을 보십시오.
이 간단한 특성을 가지고 당신의 개발 작업 흐름은 더욱 호응성을 느끼기 시작했고 피드백 순환 시간이 현저히 감소했다.

수정되지 않은 오류

또 다른 저의 Flow 체험을 파괴한 일은 Flow 자체에서 복구되지 않은 버그의 수량입니다.
예를 들어, Vuex을 설치할 때, 모든 Vue 구성 요소는 하나의 추가 속성으로 확장되며, this.$store을 사용하여 이 속성에 접근할 수 있습니다.문제는 FlowVuex이 추가되었다는 것을 알려줄 방법이 없다는 것이다.그리고 this bug은 2015년에 개업하여 지금까지 4년이 되었습니다!
물론 자신의 유형을 작성할 수 있습니다.

// @flow

import Vue from 'vue'
import type { Store } from 'vuex'

import type { State } from '~/types/vuex'

/**
* Represents our extended Vue instance.
*
* We just use the annotations here, since properties are already injected.
* You will need to add new annotations in case you will extend Vue with new
* plugins.
*/
export default class CustomVue extends Vue {
  $store: Store<State>
}

하지만 이제는 스스로 자신의 유형을 지켜야 한다.this.$router 속성을 추가하시겠습니까?직접 추가하십시오.Nuxt 특정 유형?너는 너 자신에게 의지할 수밖에 없다.
이를 the standard TypeScript 방법과 비교합니다.

import Vue, { ComponentOptions } from "vue";
import { Store } from "./index";

declare module "vue/types/options" {
  interface ComponentOptions<V extends Vue> {
    store?: Store<any>;
  }
}

declare module "vue/types/vue" {
  interface Vue {
    $store: Store<any>;
  }
}

특수 성명을 사용하여 기존 유형을 확장할 수 있습니다.도서관의 작가가 너를 위해 이런 것을 해 주었다.내가 말한 유형 분포 기억나?이 기능은 분포를 더욱 완벽하게 한다.
2015년 second well-known bug은 반드시 필요하더라도 this을 주석할 수 없다.일부 라이브러리에는 이상한 API가 있습니다.Flow이 있으면 너는 아무것도 할 수 없고, 타자는 그곳에서 보이지 않는다.그러나 TypeScript이 있으면 모든 상하문에서 this의 뜻을 주석할 수 있다.이것은 많은 용례에 대해 말하자면 매우 좋은 것이다.
왜 이 버그들은 복구되지 않았습니까?몰라요.요 몇 년 동안 그들은 많은 관심을 불러일으켰다.많은 사람들이 이런 것을 원하지만 Flow팀은 이 프로젝트에 대한 소망을 공유하지 않았다.그들은 지역 사회가 아니라 그들이 원하는 것을 발표했다.

발표하다

발표에 대해 말하자면, 나는 반드시 그들의 정책을 언급해야 한다. "일부 것만 발표하고, 사용자로 하여금 그들의 코드를 복구하게 한다."이것은 the release history과 그것이 나의 프로젝트에 한 일이다.거의 모든 버전이 나의 코드를 파괴할 것이다.코드가 거의 없는 템플릿이라는 것을 감안하면 정말 무섭다.
그나저나 Flow팀은 SemVer를 따르지 않았고 증량만 발표했다.jsx의 .vue 버전 이후에 파일이 작업을 중지합니다.나는 새 버전에서 그것을 다시 복원할 수 없다.나는 게으른 길을 걸었다. 버전을 잠그고 이 사건 이후 업데이트를 소홀히 했다.TypeScript은 clear release policy, SemVer를 보유하고 있으며 사회의 광범위한 관심을 받고 있다.장기적으로 보면 이런 상태를 유지하는 것이 훨씬 낫다.

결론

우리는 이미 said "Good bye"에서 Flow을 선택했다.현재 우리의 모든 프로젝트와 프로젝트 템플릿은 TypeScript을 지원합니다.우리는 아무것도 후회하지 않는다!
겸사겸사 한마디 하자면, 우리의 틀은 정말 훌륭하다.지원:

Nuxt 서버 측 렌더링 및 템플릿 파일 격리

TypeScript: 코드, 테스트, 구성

Jest는 유닛 테스트, TestCafe는 E2E 테스트

Docker for development and production

Awesome documentation, 프로젝트의 각 방면을 포괄하는

Try it out !