neverthrowと比較したoption-tについて - saneyuki_s log
たまたまoption-tを紹介してくれるブログ記事があったみたいで、その上でneverthrowの方がおすすめみたいな感じのtweetを見かけて、色々言いたいことがあったので久々に書いてみる。 https://t.co/GJGyxeyoZM fp-ts を入れるのを躊躇う環境で Result 型とコンビネータが欲しい場合の私のおすすめは neverthrow です— naoya (@naoya_ito) 2023年1月19日 ・ResultAsync という async に対応している ・fromPromise / fromThrowable を使えば Result の入れ子が嫌なときに async/await や例外を使った普通の手続きで書いて、fromPromise/Throwable で包むという回避手段が取れる— naoya (@naoya_ito) 2023年1月19日 ・Res
Reactのprops/contextの使い分け - saneyuki_s log
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針
BEMで底に達した問題を探す問題のために生まれる問題 - saneyuki_s log
最近、社内のいろんなプロジェクトのリポジトリを眺めているとスタイルシートの記述にstyled-componentsとかwebpackのcss-loaderとかで頑張っているものを頻繁に目にする。 んで、Lintとかどうしてるの？みたいな話をすると「〜はこの『A（どこかのCSS-in-JS派閥の一つ）』は対応してないんだよねー」という返答が返ってくる。 そのたびに思う。「BEMで問題解決してたんだからBEMでいいじゃん」と。 このようなことを言うと「JVMのJITコンパイラの仕組みを聞いた後に『アセンブラを生で書けばいいじゃん』と言い出す痛いおじさん」感がするので自分でもあんまり好きじゃない。ただ、CSSに関してはBEMで問題が底に達してしまっていて、そこから先の標準化されてないwebdevツール群は問題を再発明しているだけに過ぎないなと思う。 書き味をどう頑張ろうが結局我々はCascadi
EdgeHTMLを悼む - saneyuki_s log
久々に色々書きたい気持ちになった + 矢倉さんの書かれたものを見て、彼とは微妙に考えることは違うかなあと思ったので書くだけ書いてみる。意見似てるなと思ってるところは書かないようにはした（標準化方面周りとか）。あと、Webブラウザ周りの現状に明るくない同僚や友人向けのテイストは含んでいる。 そもそもの大前提 まず、Webという文書・アプリケーションプラットフォームの価値は「標準仕様に基づく相互運用性」「インストールせずとも使える」の二点に集約されると自分は思っている。 最近はずいぶん聞かなくなった「Webは簡単に作りやすい」というメリットは、「Win32のデスクトップアプリに比べると」という但し書き付きで、90年代は事実だったと思うけど.NET Frameworkの進化とかモバイルOSアプリが出たりとか業界の成熟に伴って事実ではなくなって久しいと思う。 この「標準仕様に基づく相互運用性」とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
