情報更新

last update 04/04 01:45

ツイート検索

 

@koichik
サイトメニュー
Twilogユーザー検索

Twilog

 

@koichik

koichik@koichik

Stats Twitter歴
4,367日(2008/04/21より)
ツイート数
6,644(1.5件/日)

ツイートの並び順 :

表示するツイート :

2020年01月12日(日)1 tweetsource

2019年11月22日(金)1 tweetsource

2019年06月28日(金)1 tweetsource

2019年06月25日(火)2 tweetssource

2019年06月18日(火)5 tweetssource

2018年10月30日(火)4 tweetssource

10月30日

@koichik

koichik@koichik

@mizchi FBが元々Redux嫌いらしいとかGraphQLだとかでコミュニティというか少なくともうちらとはズレた感じだったけど、Suspenseに続いてHooksが来てあっちが王道になるのが決定的という印象を受けたんだよね。なので彼らは変わらないかもしれないけれど、うちらは影響大きいかなと。うちらというか自分だけ?

posted at 18:40:46

10月30日

@koichik

koichik@koichik

@mizchi ReduxのSingle sourceとかReact Router v3までのルート定義のような中央集権的な存在が弱くなり、より自律的なコンポーネントの集合体としてアプリが構成される(Micro Frontendな)傾向が強くならないかな。Suspense込みの話になってしまうけど。なので全体設計にも大きな影響を与える可能性あるかなと

posted at 17:53:04

10月30日

@koichik

koichik@koichik

@mizchi ドキュメントでは既に SFC って記述はなかったぽい。gist に貼ったリンクの2つめでソースからも "stateless" が消された。

posted at 17:28:04

2017年07月19日(水)1 tweetsource

7月19日

@koichik

koichik@koichik

@kawasima こっちの世界で普及する前は (主にビジネス用語かな、HBRの見出しとか) アジルって訳語が使われてたのを思い出した。

posted at 15:14:03

2017年06月30日(金)3 tweetssource

6月30日

@koichik

koichik@koichik

世間では毎月最終金曜日はプレミアムフライデーらしいですね。ちなみに自分の場合は毎週金曜日になると正面に @yosuke_furukawa 隣に @mizchi 斜め前に @t_wada が座っててとってもプレミアム。プレミアムエブリーフライデー。

posted at 22:45:33

2017年06月28日(水)1 tweetsource

6月28日

@koichik

koichik@koichik

@yosuke_furukawa D-WAVEが並んでるデータセンターの画像が弊社かと思ったら会議室の方かw
RCOがD-WAVE持ってるって聞いてたけどこんなにたくさん!?って驚いた後なのでちょっと拍子抜け

posted at 21:47:31

2017年06月20日(火)1 tweetsource

2017年06月17日(土)2 tweetssource

6月17日

@koichik

koichik@koichik

@kazu_pon ストリーム化しただけじゃCPUの使用時間は減らないからねぇ。fiberも同様(イベントループに戻るメリットはもちろんあるけど)。1ページのレンダリングにCPUを100ms使ったらどのやり方でもスループットは1プロセス10rpsで頭打ちなので当面はCPU時間を削ることが最大の課題。

posted at 17:52:16

6月17日

@koichik

koichik@koichik

@hakobera AMPは今まで「在庫あり」「予約可」的なリアルタイムな情報を扱いにくかったけど<amp-bind>等が出てきて使えそうになってきましたね。とはいえAMPはSSR(してクロールしてもらう)だしto PWAしてCSRするコンポーネントは大体AMPと共通だしでやっぱりIsomor文字数

posted at 17:21:48

2017年05月31日(水)1 tweetsource

2017年05月30日(火)2 tweetssource

5月30日

@koichik

koichik@koichik

@Nkzn <RouterContext>がいるのでreact-router v3ぽいですね。Twitter Liteのリリース時期的にもv4は採用しにくかったのではないかと。

posted at 22:44:37

2017年04月30日(日)3 tweetssource

4月30日

@koichik

koichik@koichik

@wyukawa プレミアでもボールに覆い被さってリスタート邪魔したボールボーイをアザールが蹴っ飛ばしたことあるからなぁ。他リーグなら別のボール使ってリスタートできるけどプレミアではどうしようもないからむしろ揉めやすいんじゃ?

posted at 16:54:24

2016年08月25日(木)1 tweetsource

2016年08月19日(金)1 tweetsource

2016年08月11日(木)1 tweetsource

2016年07月29日(金)1 tweetsource

7月29日

@koichik

koichik@koichik

@yosuke_furukawa プロダクションでpropTypesがチェックされないのはReactが元からなのでこっちでは何もしてないです。最適化のプラグインだとconstant-elementsとinline-elementsは使ってる。

posted at 01:43:39

2016年07月10日(日)1 tweetsource

2016年07月08日(金)1 tweetsource

7月8日

@koichik

koichik@koichik

@Jxck_ 記憶になかった「末代までの恥」検索したら普通に出てきた。鳥頭だから記憶にないけど。でも悪くないモンスターに「お前はアーキテクトに向いてない」なんていった記憶は一切ない(きりっ

posted at 23:54:34

2016年06月30日(木)1 tweetsource

2016年06月24日(金)7 tweetssource

6月24日

@koichik

koichik@koichik

@yosuke_furukawa @bouzuya Babelとの相互運用と言った場合はトランスパイル後のCJSモジュール (__esModule: trueでns.defaultがありns !== default) とネイティブESモジュールの相互運用かなぁ。

posted at 02:45:32

6月24日

@koichik

koichik@koichik

@bouzuya はい、その認識です。そしてCJSをESにマッピングしようとすると、 ns.default = ns (ns.default = default と同じ) が出てくるハメに。それがBabelのアレ。

posted at 02:35:07

6月24日

@koichik

koichik@koichik

@bouzuya ESのdefaultはExportEntry Recordの1レコードに過ぎない(export名がdefaultなだけでexport var vのvと同等)ので、ExportEntry Records全体に対応する名前空間と別なのは明かでは?

posted at 01:22:28

6月24日

@koichik

koichik@koichik

@bouzuya ここポイントかもですね。ESでは名前空間とデフォルトは明確に分かれてるけれどCJSではそうではない。しかしどちらかが「無い」のではなく、module.exportsが両方の用途で使われてきた。使い分けではなく同時に併用するモジュールも多い。という現実との相互運用

posted at 00:16:42

6月24日

@koichik

koichik@koichik

@bouzuya CJSにおいてユースケース的にdefaultに相当するものとして、特にsubstackパターンと呼ばれる広く使われているイディオムがあると認識されているからではないかと思います。

posted at 00:14:52

2016年06月23日(木)7 tweetssource

6月23日

@koichik

koichik@koichik

@bouzuya 既存CJSモジュールとの相互運用という観点だとmodule.exports.defaultなんてほとんど誰も使ってこなかったのでimport x from ~が成立しなくて前提にするのは無理があるのでは。

posted at 23:16:34

6月23日

@koichik

koichik@koichik

@bouzuya ん?「これから書くCJSモジュールがきれいにESモジュールにマッピングされる方法」と「既存のCJSモジュールを何とかESモジュールにマッピングする方法」で齟齬がある?

posted at 23:10:07

6月23日

@koichik

koichik@koichik

@bouzuya TS側の意図は知らないのですがES仕様のセマンティクスを考慮してるようには見えないですよね。従ってTSよりはNode案やBabelの方がES仕様に近づけようとしていると言えるのでは?

posted at 21:15:36

6月23日

@koichik

koichik@koichik

@bouzuya ES仕様ではexport defaultがns.defaultになるので、CJSではmodule.exports.defaultではなくexport default相当であるmodule.exportsがns.defaultになる方がES寄りかと。

posted at 21:13:54

6月23日

@koichik

koichik@koichik

@bouzuya Node案はread onlyにしようとしてる分BabelよりES寄り、TSは見た感じr/oでもなくimport * as nsでnsにdefault (import x from~した時のx)が入らなさそうで一番ES仕様から遠そうに見えます。

posted at 05:16:12

6月23日

@koichik

koichik@koichik

@bouzuya ごめんなさい、BabeったESモジュール同士でも壊せました… 仕様見てるとimportは新しいListを作るようにしか見えないけど… 自分の誤読かもです。

posted at 02:08:27

2016年06月22日(水)6 tweetssource

6月22日

@koichik

koichik@koichik

@bouzuya 仕様ではimport側とexport側は異なるRecordのListを持つのでimportした側がモジュールのexportメンバを増減したり差し替えたりはできないはずですが、TypeScriptのimport * as nsではどうですか?

posted at 22:09:20

6月22日

@koichik

koichik@koichik

@bouzuya import側とexport側は抽象的なRecord(15.2.1.15)で間接的につながるので、それらを(通称バインディングと呼ばれてる)オブジェクトで表現しているのではないかと。

posted at 22:08:06

6月22日

@koichik

koichik@koichik

@bouzuya export側のパース時に作られるべき情報 (15.2.1.16.1の10~11)で、Babelでトランスパイルされたモジュールなら既に用意済みなのでimport時に作る必要がないからでは。

posted at 22:07:25

6月22日

@koichik

koichik@koichik

@bouzuya BabelはCJSモジュールをESモジュールにマップしようとしてますが、gistを眺めた限りTypeScriptはESモジュールの「構文だけ」をCJSに適用してるように見えますね。ESモジュールのセマンティックスはガン無視のようで正解にほど遠いような?

posted at 17:06:01

このページの先頭へ