なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介

このブログを書いてる経緯 rust.tokyo 楽しみ！絶対行く！といってたのに申込みを忘れたところ、じゃあスタッフとしてブログを書けという話になったので、ブロガー枠？らしく感想を書きます。とはいえ書けるのは見たやつだけです。 https://rust.tokyo/sessions# 前提 自分は低レベルプログラミングは詳しくないです。年に3日ぐらい思い出したように Rust 勉強することがある。 wasm 周りのエコシステムはずっと追ってる。 会場の雰囲気 組み込み勢とブロックチェーン勢が多そうな気配を感じた。 Visualization of mechanical CAD drawings using WebAssembly and WebGL Aki / CADDi (発表資料見つからず) 概要 Computer aided design (CAD) models used in m

今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる

某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty

基本的に、ReactのpropsはImmutable, stateはmutableという扱いです。 storeはストレージ抽象じゃない— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 rootComponent以外のComponentで参照するプロパティは基本的に全てpropsになるしstoreからの関数読み出しみたいな動的な状態決定は行わない— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 そもそもViewを論理的に分割しても人間のよくわからん都合でしっぺ返し食らうだけなんでコンポーネントが独立して稼働するなんて状態になりにくくて、一意な状態を作るのに一旦一箇所に集約した上で各コンポーネントに発散するのがいい— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 @r7kamura 親が正しいprops持ってれば、結果として正しいpr

https://github.com/mizchi/sketch-board 自分は簡単な図形の描画にSVGの手書きは全然アリだと思っていて、Jadeテンプレートで書きなぐることができるようにした。 AtomShellで作った

なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ

1時間あるので、年末年始の大掃除のお供にどうぞ #13 Virtual DOM | mozaic.fm 内容 仮想DOMに対していつも主張していることの要約 各実装の空気感、手触り感 実際に仮想DOMってどこに訴求できるんだろうね 現実的に採用可能なのか、いつ採用可能なのか、求められるスキルセットは etc. Rebuildにも出たので松田さんに続いて両方に出演したことになる…とはいってもRebuildはAfterShowほんのちょっとだが 反省 話を切り出すときが「そうですね…」で始まってワンパターン もっとはっちゃけてよかった。あんまり笑ってなくて妙に緊張感がある感じになってしまった 相槌が相手を食い気味 とくに相槌は難しかったので、次に出る人は参考にしてください。

最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue