TypeScript で string 型の値に自動補完を効かせる: Days on the Moon
結論 type X = 'foo' | 'bar' | (string & {}); のように、文字列リテラル型の共用体型に | (string & {}) を付け足した型 X を定義します。X 型は任意の文字列を受け付けますが、IDE (Visual Studio Code など) で X 型の値を入力するときには 'foo' と 'bar' が自動補完の候補として提示されます。 解説 単純に type X = 'foo' | 'bar' | string; と書いてしまうと、共用体型の各要素がまとめられて、X は単なる string 型になってしまいます。{} 型は null と undefined を除く任意の値を受け付けるので、string & {} 型は実質的に string 型と同一なのですが、TypeScript 4.4 の時点では同一扱いされず、共用体型の各要素がまとめられ
JavaScript で構文解析: Days on the Moon
C++ の特徴のひとつである演算子オーバーロード、その粋を極めたのが Boost Lambda (無名関数) と Boost Spirit (構文解析) ではないかと思っています。JavaScript では無名関数が使えるので Lambda に関しては間に合っているとも言えますが、Spirit はそうも行きません。JavaScript 2 で演算子オーバーロードがサポートされるのならチャレンジしてみようかななどと思ってそれきりになっていました。 しかし、一部でパーサブームが起こっているというのを受け、Perl 6 Rules をつらつらと眺めているうち、正規表現のメタ文字を使えば文法定義をきれいに書けるのではと思い至りました。そこで実際に JavaScript でパーサジェネレータを作り、Spirit にあやかって Gin (ジン) と名づけてみました。 文法定義 正規表現リテラルを使うこ
リンクのようなボタンを作る: Days on the Moon
こんばんは、JavaScript Advent Calendar 2010、15 日目担当の nanto_vi (なんと) です。12 月 15 日が何の日か調べてみると東北本線が宮城県に到達した日とのこと。当時は上野から仙台まで 12 時間 20 分かかったそうです。それから 123 年を経た現在では同じ時間で鹿児島中央から新青森まで行けるようになり、鉄道の速度にも JavaScript の実行速度にも日進月歩を感じる今日この頃です。 さて、アプリケーションを作っていると、見た目はリンクのようだがリンクでない UI 部品を使いたくなるときがあります。ここで「リンクでない」とは、クリックしてもページ遷移が発生しないということです。このような UI 部品は、ページ遷移の代わりにメニューの表示といった何らかのアクションを引き起こす、すなわちボタンとして振舞います。 ユーザーインターフェース記述
第 2 回 Firefox 出張ワークショップ発表資料: Days on the Moon
先日京都コンピュータ学院で開催されたオープンソースカンファレンス 2009 Kansai、その中の一セッション「第 2 回 Firefox 出張ワークショップ ～基礎から学べる拡張機能開発～」に講師として参加させていただきました。私の担当した後半、実際に拡張機能を作ってみる部分の資料及び完成版の拡張は以下になります。 Firefox 拡張機能開発ワークショップ in OSC Kansai 2009 contexthistory-0.1.xpi ソースコード chrome/ content/ contexthistory.js contexthistory.xul chrome.manifest install.rdf 「わからないことがあったとき、どうやって調べるか」をひとつの柱として話を進めていきたかったのですが、つたない進行で後半ややペースが押し気味になってしまい、終了時間を 5 分ほ
Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
