대응 - TypeScript vs Flow vs.

대응 - TypeScript vs Flow vs.

리액트를 배우고 있는데 잘 알 것 같아요.하지만 강력한 Respect 어플리케이션 개발과 관련하여 한 가지 궁금한 점이 있습니다. 개발자들은 정적 유형 확인을 위해 어떤 툴을 사용하고 있습니까?

저는 TypeScript를 정말 좋아합니다.타입 체크 등 깔끔한 기능으로 JavaScript 어플리케이션 개발의 번거로움을 많이 줄일 수 있다고 생각합니다.Visual Studio Code는 또한 매우 훌륭한 코드 완성도를 제공합니다.그리고 타이핑 + Denifly를 사용하여 React와 연동할 수 있다는 것을 알고 있습니다.입력.

문제는 React + TypeScript 사용에 대한 튜토리얼이 많지 않다는 것입니다.이 조합으로 개발한다는 기사도 별로 없는 것 같습니다.한편, 많은 사람들이 Facebook이 지원하는 프로젝트인 Flow를 사용하고 있는 것 같습니다(그들도 사용하고 있다고 생각합니다).

React + TypeScript / React + Flow 방식에 대한 찬반 양론으로 Reddit에 대한 논의를 할 수 있었습니다.하지만, 10개월 정도 된 것 같기 때문에 꽤 구식인 것 같습니다.그때 이후로 많이 변한 것 같아요.

또한 React + Flow와 React + TypeScript 사용에 대한 두 가지 기사를 발견했습니다.저자는 두 옵션을 모두 사용할 때 마주친 몇 가지 문제를 언급하고 TypeScript가 "현재로서는 최선의 선택"(2015년 11월)이라고 결론짓습니다.특히 Flow 프로젝트는 많은 문제가 있어 Facebook으로부터 개발자 액티비티가 낮기 때문입니다.바벨과 잘 어울리지 않는다고도 하던가요?

문제는 React + TypeScript 콤보를 사용하는 것이 안전한가?아니면 문제가 생길까?Flow는?비슷한 도구가 또 있나요?어떤 접근방식을 추천하시겠습니까?

2017년 9월 갱신:

TypeScript를 1년 이상 일상적으로 사용하고 Flow를 잠시 사용해 본 결과 다음과 같은 결론을 얻었습니다.

• TypeScript는 오늘날까지 사용하기에는 여전히 괴롭습니다.문제는 JavaScript 월드가 너무 빨리 움직이기 때문에 TypeScript는 계속 뒤처진다는 것입니다.그 멋진 ES7 스테이지 3 기능을 사용하실 생각은 없으십니까?아니, 넌 못 해.일부 라이브러리의 최신 버전에 대한 유형 힌트를 얻고 싶으십니까?한 달, 두 달, 어쩌면 더...
• 흐름은 크게 발전했고, 많이 개선되었으며, TS가 포착할 수 없는 몇 가지 사항을 포착할 수 있습니다.무엇보다도, 그것은 마침내 Windows에서 작동한다.또, VS Code용의 플러그 인도 있습니다(왜 3/5 밖에 없는지는 알 수 없습니다).React Native에서는 100% 동작합니다.TypeScript는 아직 50%도 되지 않았습니다.
• 대부분의 경우 활자가 전혀 필요하지 않습니다.추가 입력은 거의 가치가 없습니다.JS는 동적으로 입력된 언어이므로 극복하십시오:)

TL;DR: 유형 검사기를 사용할 계획이라면 Flow를 사용할 것을 권장합니다.

2019년 2월 갱신:

저는 위의 권고가 시대에 뒤떨어져서 더 이상 관련이 없다고 생각합니다.3가지 이유:

• 리액트 훅이 왔어요코드를 훨씬 쉽게 확인할 수 있습니다.대부분의 경우 추가 코드는 필요하지 않습니다.
• TypeScript의 유형 추론이 개선되었습니다.
• TypeScript는 Flow보다 훨씬 더 큰 커뮤니티를 가지고 있습니다.심지어 Facebook의 패키지 매니저인 Yarn도 Flow에서 TypeScript로 옮기고 있다.

따라서 2019년에는 Flow보다 TypeScript가 훨씬 실용적인 선택이라고 생각합니다.

활자 체커를 사용할 가치가 있는지 여부에 대해서는 프로젝트 규모에 따라 다르다고 생각합니다.소규모 프로젝트에서는 아마 이것이 필요하지 않을 것입니다.

Flow를 사용해 본 적이 없기 때문에 자세한 것은 말할 수 없습니다.하지만 회사에서는 React와 TypeScript를 사용하고 있기 때문에 매우 효과적입니다.

리팩터링, 타입 세이프티, 오토 컴플리트먼트 등 이미 알고 계신 모든 장점을 갖추고 있습니다.

물론 제가 본 바로는 Flow 구문은 TypeScript보다 깨끗하지만 TypeScript를 사용하여 유형을 점진적으로 추가할 수 있습니다.이건 취향의 문제라고 생각해요.어떤 사람들은 코드를 명시적으로 입력하는 것을 선호하고, 다른 사람들은 덜 입력하고 더 강한 유형 추론을 선호합니다.

TypeScript에 대해서는 Microsoft가 이 언어를 추진하고 있으며(버전 2가 곧 출시될 예정), Angular도 이 언어를 사용하고 있으며, 많은 Angular 개발자가 있습니다.여기 SO에서도 태그 TypeScript는 4K명 이상의 팔로워를 가지고 있으며 답변이 없는 질문은 거의 없습니다.

적어도 우리에게 TypeScript의 큰 문제는 때때로 유형 정의가 없는 컴포넌트나 라이브러리를 사용하기로 결정했기 때문에 직접 작성해야 한다는 것입니다.하지만 그게 지역사회에 다시 기여하는 방법인 것 같아요.

같은 질문을 스스로에게 던졌을 뿐(React는 아니지만) 다음 기사가 이 두 가지를 평가하는 데 도움이 된다는 것을 알게 되었습니다.

• http://michalzalecki.com/typescript-vs-flow/ (2016-07-15)
• https://blog.wearewizards.io/flow-and-typescript-part-2-typescript (2015-11-20)
• https://blog.wearewizards.io/flow-and-typescript-part-1-flow (2015-11-13)

흐름 설계자가 취하는 접근방식은 더 나은 유형 추론 및 null에 대한 더 나은 접근방식으로 더 기능적으로 느껴집니다.단, TypeScript는 특히 http://definitelytyped.org/을 통해 서드파티 라이브러리의 유형을 가져오는 것에 관한 커뮤니티 지원이 우수합니다.이는 타입의 안전성을 최대화하기 위해 모든 코드에 타입이 흐르도록 하는 데 중요합니다.TypeScript는 컴파일러를 작성하고 테크놀로지를 바람직한 방향으로 진화시킨 풍부한 역사를 가진 Microsoft에 의해 작성되었습니다.여기서 주목되는 것은 C#입니다.또한 이미 C#에 비표준 타입을 추가하고 있다는 사실(2016-07-11)도 있습니다.https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

오늘날 TypeScript가 더 안전한 것 같습니다.

또한 기존 코드베이스에서 TypeScript를 실행하려는 사용자에게 tsconfig.json 파일의 다음 설정은 TypeScript가 JavaScript와 원활하게 공존할 수 있도록 하는 데 매우 도움이 됩니다(한 번에 한 파일씩 전환 가능).

{
    "compilerOptions": {
        "allowJs": true,
        "isolatedModules": true,
        ...
    }
}

리액트 개발에서는 상당히 복잡한 Babel / Webpack / Flow / Mocha 툴체인을 셋업하여 Flow에 문제가 발생한 적이 없습니다.모든 것을 셋업하는 데 약간의 노력이 필요하지만(Webpack은 처음에는 힘이 들 수 있습니다), 그 후에는 그냥 작동합니다.플로우는 폭이 좁고 집중도가 높은 테크놀로지이기 때문에 다른 툴과 잘 연동할 가능성이 높기 때문에 확실히 바람직한 방법입니다.이와는 대조적으로 TypeScript는 단순한 유형 추론/정적 유형 검사 도구 이상의 것을 시도하기 때문에 추가적인 짐과 가정을 가져옵니다.따라서 React는 한 가지 기능을 수행하는 전문 도구이며, TypeScript는 JavaScript 위에 효과적으로 레이어된 언어입니다.Microsoft 가 포인트 홈을 확실히 하기 위해서, TypeScript 파일에는 통상, 다른 확장자가 붙습니다( )..ts대신.js다른 언어를 사용하고 있기 때문에, 알겠습니까?

TypeScript는 코드 생성을 사용하여 JavaScript를 뱉어내는 반면 Flow에서는 단순히 주석이 제거되며 코드 생성은 없습니다.과거 TypeScript를 홍보하는 마이크로소프트 직원들은 코드 생성은 "파일 로컬"이라는 취지의 발언을 했습니다(사용된 정확한 용어는 기억나지 않습니다).이것은 TypeScript 컴파일러가 마법 같은 일을 하고 있지 않다는 것을 안심시키기 위한 것이었다.어쨌든 나는 그 진술이 더 이상 눈에 띄도록 전시된 것을 찾을 수 없다.Flow를 사용하면 일반 JavaScript(또는 Babel을 설정한 ECMA 버전)로 기술하는 것과 같은 보증은 필요 없습니다.주석은 앞서 말한 바와 같이 단순히 삭제되어 있습니다.

TypeScript가 비윤리적이고 의심스러운 기술 실무 전문 회사에서 나온다는 것은 말할 것도 없고(TypeScript가 결국 모든 포용-확장-확장-확장-확장-확장-확장-확장-확장-확장-확장-공략의 어머니로 판명될 수도 있음)마이크로소프트가 Javascript를 실패시키기 위해 할 수 있는 모든 일을 했다는 것을 잊지 말자.그들은 Javascript가 그들의 형편없는 운영체제와 비대해진 오피스 제품군에 어떤 위협이 될 것인지 (지금은 맞지만) 예견하고 있었다.

또한 Flow의 Type System은 TypeScript (2015년경)를 평가했을 때 훨씬 더 강력했고, 소스에서 증분 또는 산발적으로 적용하는 것이 훨씬 쉬웠습니다.서드파티 라이브러리를 통합하기 위해 저는 flowtype을 사용하고 있으며, 거기서 발견된 라이브러리를 제 정의로 보완해야 하는 경우는 거의 없습니다.

마지막으로, Angular가 TypeScript를 사용한다는 사실은 Angular가 새로운 프로젝트와 관련이 없기 때문에 전혀 의미가 없습니다.리액션이 수월하게 이겼으니, 앞으로 나아가야 할 시간이다.

타입 체크를 원하지만 (컴파일이나 휴대성 등을 위해) 오래된 javascript를 유지하고 싶은 경우, 두 가지 중요한 차이점을 하나 제시합니다(React 또는 일반).

• Flow를 사용하면 초기 셋업은 vanilla js에 대해 정적 분석을 실행할 수 있습니다(다양한 유형을 추론합니다).

  function square(n) {
    return n * n; // Error!
  }
  
  square("2");
  

• TypeScript 에서는 이행이 이루어지며 이행이 이루어지지 않는 정적 분석은 몇 가지뿐입니다.
  • noImplicitReturns기능 종료 시 되돌아오는 것을 잊지 않도록 합니다.
  • noFallthroughCasesInSwitch스위치 블록내의 케이스간의 브레이크 스테이트먼트를 잊지 않는 경우에 도움이 됩니다.
  • 또한 TypeScript는 도달 불능 코드와 라벨에 대해 경고합니다.이러한 코드는 allowUnreachableCode를 사용하여 비활성화할 수 있으며Unused Labels(각각각.

흐름의 다른 이점

Flow의 주석 유형 및 오류 억제는 한 단계 더 나아가 유형에 주석을 달거나 아직 준비되지 않은 특정 체크를 억제하는 법적 j 주석을 통해 유형 체크를 점진적으로 통합할 수 있도록 함으로써 바닐라 js를 지원합니다.댓글 타입은 오랫동안 TypeScript의 기능 요청이었지만 최근에서야 PR이 있었습니다(이전 링크 참조).

흐름의 단점

즉, Flow의 모든 단순성은 서드파티 라이브러리의 타입 체크 방법 등 귀찮은 경고와 함께 매우 복잡한 구성을 희생합니다.Flow에 대해 누군가가 할 수 있는 가장 좋은 조언: 문서에서 읽은 내용은 모두 상호 참조하도록 하십시오. 오래된 내용이고 경우에 따라서는 오해를 일으킬 수 있습니다.

언급URL : https://stackoverflow.com/questions/36872248/react-using-typescript-vs-flow-vs