flowtypeバッドノウハウ - blog
flowtypeを使ってみて個人的にはまったところ。 v0.65.0時点での話です。仕様なのかバグなのかわからない話も含みます。 enumの罠 flowのenum(正しくはUnion Type)は条件分岐などで、含まれないはずの値と比較しているとエラーを出してくれる。 /* @flow */ type A = "hoge" | "huga" const a: A = "hoge" if(a === "humu") { console.log("hoge") } // 7: if(a === "humu") { // ^ string literal `humu`. This type is incompatible with // 5: const a: A = "hoge" // ^ string enum ただし、これはObjectのプロパティに対して働かない。 /* @flow */
BFFの設計とflowtype - Qiita
株式会社FOLIOのフロントエンドエンジニアをしています、諸見里です。 この記事はFOLIOアドベントカレンダー7日目の記事です。昨日の記事はバズらせてサーバーを落とすことで有名な弊社CDOの超心に刺さってイヤでも印象に残るプレゼンの方法でした。それほどバズらずサーバーは落ちなかったようです。 会社のアドベントカレンダーということで、今回はFOLIOのBFF(Backend For Frontend)でのflowtypeの活用と、アーキテクチャについて書きます。 BFF & Microservices FOLIOのシステムは、Scalaを中心としたマイクロサービスで構成されています。そして、それらのサービスをクライアント向けに束ねるために、Node.jsで書かれたBFF(Backend For Frontend)を置いています。例えばWebアプリ用のBFFなら、各サービスからデータを集めて
少人数でのフロントエンド開発をクイックに進めるために - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 7日目の記事です。 昨日の記事は@yue82さんでRTL設計スタイルガイドのアンチパターンをやってみたでした こんにちは。ニコニコ静画でフロントエンド開発を行っているnagisioです。 今年も冬コミに落ちてしまいました 去年の記事はRe:ゼロから始めるElectron開発生活でした。Electronに関して、残念ながら最近はあまり書いてないのですが、Reactは既に趣味でも仕事でも必須なフレームワークとなりました。 本記事ではそんなReactを用いたプロダクト開発について、どのように開発を進めていくのかを追っていきます。 はじめに（宣伝枠） ニコニコ静画チームにおいて、フロントエンドでの新規開発は基本的に少人数（１〜２人程度）で行っています。比較的小規模な開発が多く、例えば直近でリリースしたのがニコニコ漫画@C93です
さよならボイラープレート。s2sによる高速reduxアプリケーション構築 - Qiita
まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード
Chrome Headless Browserを触った所感と、Flowtype・ES2017構文を使ってChrome Headless Browserを動かすライブラリを作っている話。 - @teitei_tk Blog
Chrome Headless Browser、思った以上に需要ありそうなので書いてみます。 まずは触った所感ですが、社内LTの際に喋った資料があるのでそちらをペタッと。 まとめると Phantom.jsの死亡 唯一のメンテナが今後はChromeHeadlessに乗り換えるであろうとメンテナを辞任 Google グループ 今後の構想はあるのか、phantomiumというPhantomJS + ChromeHeadlessの単語が組み合わさったレポジトリはある。 github.com Googleが開発している安心感 今後Chromeを手放すことはそうそうないと思うので、今後のベストプラクティスになる可能性が高い。 Production環境への投入は待ったほうが良い。 謎の –disable-gpu Option APIが落ち着いていない。 devtools-procotol viewerと
なぜTypeScript推しなのか - Islands in the byte stream
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
Electron + Vue + flowtypeで最高の画像を収集するためのTwitterクライアントを作った - Qiita
Electron + Vue2 + Vuex + Flow + BootStrap4 + AWS RekognitionのスタックでTwitterクライアント書きました。 本アプリは【Electron + react + flowtype】TweetDeckライクなpixivクライアントPixivDeckをつくった - Qiita に思想・設計共に大きく影響を受けて作りました。本当にありがとうございます。 Github - yuki-ycino/imecoletter: 最高の画像を集めるためのTwitterクライアント 諸事情（というか実装の都合上AWSの請求が大変なことになるため）バイナリの配布はできません。 簡単にビルドできるようにはしてあるのでもし興味がある方がいれば使ってみてください。 スクリーンショット TwitterのTLから画像ツイートのみを表示 Twitterから画像ツイ
flowtypeのUtility Typeについて その1 - Qiita
flowtype v0.31.0がでましたね！（既にv0.32.0もでてますけど） CHANGELOG読んでみると Added a new "magic" type called $PropertyType. This utility extracts the type of the property 'x' off of the type T. magic typeなる気になる用語があるじゃありませんか！！ どうやら$から始まる定義済みの型のことを指してるようなのですが、公式のドキュメントや過去のCHANGELOGを見てもそんなものは一切出てきません。 仕方ないので実際にコードを見てみると https://github.com/facebook/flow/blob/master/src/typing/type_annotation.ml type_annotation.mlの中に$から始
JavaScript でも型チェックと契約による設計で安定した開発をする - Qiita
チーム開発をやっていると特定の処理を呼び出す際にインターフェイスを明示することがとても重要になってきます。言い換えると使い方がきちんと示されていることが最低ラインということです。ドキュメントは実際の処理と乖離しますし、各人がソースコードの処理を追わなければならないというのはチームでやっている意味がありません。 ところが JavaScript にはそういった仕組みが存在しません。どういった処理をするのかを表すための関数名は指定できますが、 JavaScript では関数を任意の名前の変数に代入できるので実はあまり役に立ちません。 といった状況にあった JavaScript ですが、昨今のツールの登場によって事情が変わってきました。 JavaScript でもインターフェイスを明示しながら開発するにはどうすればいいかを要素技術と一緒に書いていきます。 型チェック あくまでも JavaScrip
実践投入してわかったflowtypeのメリデメ
facebook製の型チェッカ、flowを実践投入してみた結果、分かった良さと辛さを詰め込みました。
flow-typedで外部ライブラリの型定義を使う - Qiita
flow-typed とは flowtype で外部ライブラリを使うと欲しくなってくる型定義ファイルを集めたリポジトリになります。TypeScript には DefinitelyTyped という型情報のリポジトリがありますがそれと似たようなものです。 flowtype/flow-typed on GitHub このリポジトリではそれらの型定義ファイルをプロジェクトで使うための便利な CLI ツールも npm 経由で提供しています。本稿は flow-typed をプロジェクトで使っていくまでの設定やセットアップについて短く解説します。 CLI ツールのインストール README.md には準備が整ったら npm に公開するよ、と書かれていますが、すでに公開されていて主要な機能は使えているので npm からインストールします（2016-06-12 時点で 2.0.0-beta.5）。 特にプ
flowtypeの実現する実行時例外のない世界 - Please Drive Faster
今日こんなスライドを見かけた。 djcordhose.github.io これはtypescriptとflowtypeの違いがよく分かるすごく良いスライド。 このスライドの5ページ目に以下の1文がある。 FLOW SOUNDNESS, NO RUNTIME EXCEPTIONS AS GOAL スライドに刺激を受けたのと、最近flowtypeを触っていたのもあって、これが何を指しているか書きたくなった。 実行環境 flow: 0.26.0 typescript: 1.18.10 Flowtypeのきほん 以下のjavasciptのプログラムをflowにかけてみる。 function foo(x) { return x * 10; } foo('Hello, world!'); $ flow flow.js:5 5: foo('Hello, world!'); ^^^^^^^^^^^^^^^
babel-plugin-typecheck を使って flowtype 文法で書かれたJSをランタイムチェックする - Qiita
https://github.com/codemix/babel-plugin-typecheck を使ってみた。 これは何 babelでflowtypeの構文を使って型エラーのランタイムチェックを行う。静的解析ではない。（自分がドキュメントから見落としてるだけで静的解析を行う方法がある？） 興味を持った理由 既存コードに対してtypescriptを導入するのは大変 flowtypeは既存コードからの乗り換えは簡単だが、型チェッカの挙動が未だに不審 コード上のドキュメントとしての型 + ランタイムチェックというアプローチなら十分では ESdoc等で型を書いてもあくまでドキュメント上の指定だが、flow syntax とこれなら実行可能という点が大きい。最悪動かなくてもランタイムチェックを外せば良い。型指定はドキュメントとして残る。 Install すでにbabel環境があることを想定
Our wish to Flowtype
Sep 8, 20154 likes20,725 viewsAI-enhanced description This document summarizes a talk given about Flowtype, a static type checker for JavaScript. The talk discussed how Flowtype allows for strong type inference in React.js projects, checks propTypes statically, and is fast. While Flowtype is not a language itself and just a type checker, its type annotations use a colon instead of TypeScript's ang
JSX と TypeScript の混合 Flux または悪魔合体
JSX + TypeScript の悪魔合体 ギョーム的に気持ちになったので JSX + TypeScript をはじめました。 導入にあたってチーム内への説明を兼ねたブログ。AltJSに対して ES でいいじゃん派ですが、自分の型需要に対して 現状の Flowtype が辛みしかないのでやむをえず。 動機 紆余曲折あって結局 React を使うことにした React Component には JSX with Babel を使いたい（手書きは無理だ） UI 以外のロジックを持ったモジュールは型の恩恵に預かりたい Flowtype つらい TypeScript かー UI 周りは JSX で、その他の堅いロジックは TypeScript で書けばいいのでは？ 共存だ！！ メリットがあるのかも不明瞭ですが、分からないからこそ試してみようという感じです。JSX と TypeScript の境界
Announcing Flow Comments | Flow
As of Flow 0.4.0, you can put your Flow-specific syntax in special comments. If you use these special comments then you do not need to transform away Flow-specific syntax before running your code. While we strongly recommend that you write your code without the special comments, this feature will help people who can't fit a Flow-stripping transformation into their setup. This was one of our most r
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜ TypeScript の型システムが健全性を諦めているか - Qiita
GitHub - codemix/babel-plugin-typecheck: Static and runtime type checking for JavaScript in the form of a Babel plugin.
node_modules以下でbrowserifyされる側が自分のtransformを指定する - Qiita
Flowtype Introduction
