Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

{ "manifest_version": 3, "name": "Create markdown link", "version": "1.0.0", "icons": { "16": "logo/16.png", "48": "logo/48.png", "128": "logo/128.png" }, "description": "Create markdown link from selected text", "content_scripts": [{ "matches": ["<all_urls>"], "js": [ "content.js" ] }] } manifest_version 拡張機能が使用するマニフェストファイル形式のバージョンを指定します。現在のバージョンは3です。 早ければバージョン2は2024年6月以降に廃止され、無効になりインストール/使用できなくな
はじめに 初投稿です。 知ってたら便利になる小技が無かったのでまとめました。 「小技が知りたい...だけど検索しても出てこない...!」 そういう時に役立ちます。 比較的古いバージョンのJSでは一部の小技が使えないかもしれません。 随時追加予定です。他に小技をご存じの方はコメント欄にGO。 おことわり この記事は、あくまで"こんなやり方もあるよ"と紹介しているだけなので、何でもかんでもこれらの小技を使うと、かえってコードの可読性を下げる可能性があります。コードサイズと可読性を天秤にかけてどちらが良いかを都度確認しましょう。 記事内の間違った部分の指摘等はこの記事のコメントや編集リクエストでして下さい。 当方コードゴルファーなので、バイト数短縮小技も入れていることをご了承ください(一応該当する節には*をつけています)。 配列 配列の重複した値を削除1 const meta = ["foo",
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はAizu Advent Calendar 2015 @ababup1192の記事です。 innocentyknrさん <- 前の人 ・ 次の人 -> masapontoさん 記事の内容 AltJSの一種であるScala.jsをオススメする記事です。以下の点を軸として紹介をしていきます。ScalaとScala.jsの魅力を語り続ける記事なので、環境構築資料としては役に立たないと思います。 Webフロントエンド開発の現状と環境 言語の強み Scala.jsを使ったモダンな開発 Scala.jsとは 名称から分かる通りAltJSの一
はじめに promiseを使うとき、いつもpromiseメソッドチェーンで記載していますか? async/awaitを利用していますか? もちろん状況によって両方書くのが殆どだとは思うのですが、私はasync/awaitの方が同期的な書き方ゆえに読みやすいため、なるべくそちらで記載しています。しかしながら、エラーハンドリングが理解できていなかったため、エラーの所在を突き止めるのに苦労してしまいました。 そのため、これを機にasync/awaitにおけるエラーハンドリングについて備忘録的にまとめておきます。 この記事のまとめ; catchされるエラーはrejectのみか、throwされたエラーも含まれるか →両方catchできる async関数における処理の順序、awaitがある場合とない場合 →awaitがない場合には同期的に処理が実行され、catchできなくなる エラー処理を外側に伝播し
はじめに 私は長い間レガシーコードと共に仕事をしてきましたが、jQueryの重要性は依然として頻繁に話題に上がるトピックの一つです。ライブラリ自体は便利なままですが、それは別の時代のニーズを完璧に満たしていました。 現在、私たちは既にES2023について話していますが、過去にjQueryがカバーしていたほとんどの機能は、すでに2015年にリリースされたES6に取り込まれています。 ES6の標準は既に広範にサポートされており、96%のレベルに達しています(出典:caniuse.com)。そのため、特に要素の選択、スタイリング、アニメーション、データの取得などの基本的なタスクについては、ライブラリの使用を見直す良いタイミングかもしれません。 以下のトピックは、いくつかの標準的なjQueryのパターンと、それに相当するバニラJavaScriptでの手法を示す参考資料として役立つと思います。 要素
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇%アップ、CVR〇%アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを
既に Stage 4 になっているので諦めていたんですが、流石に見逃せないかなと思ったので TC39 の Discourse にトピックをたててみました。意見がある方はこちらにお願いします。 https://es.discourse.group/t/fix-at/983 議論に伴って私が実際に欲しかったものをモジュールにして公開してみました。 https://github.com/petamoriken/safe-at それといまいちユーザーからの声が伝わっていない感じがしたのでハッシュタグ #fix_ecmascript_at を用意してみました。協力をよろしくおねがいします。 String#char{At, CodeAt} という存在を忘れてたんですが、この似た名前のメソッドたちが引数を整数に丸めるのに String#at が丸めないのはたしかに変だということに気づいてしまったので、自
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、昨日公開された以下の記事に対するアンサー記事です。TypeScriptで型定義に凝る派筆頭(自称)として、このお題に対して別の視点から光を当ててあげるためにこの記事を用意しました。 TypeScript の型定義に凝りすぎじゃね? まず最初に、この記事(以下では元記事と呼びます)の著者を攻撃したり、元記事の内容を否定する意図はないことをご理解ください。結局のところ、考え方が異なり、前提が異なるから異なる結論になっているだけなのです。TypeScriptを使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、フロントエンドエンジニアのてりーです。 僕の詳しいプロフィールはこちら Reactを仕事で使いこなしたい人、Reactの知識に不安がある人に向けて、具体的な勉強方法のロードマップをまとめました。 この記事について この記事は、「JavaScriptでの関数型プログラミング」について、Reactを学ぶ際に足を引っ張らない程度にまとめました。 普段JavaScriptに触れていながら、Reactへの学習障壁を感じている方などの参考になれば幸いです。 なぜReact学習において、関数型プログラミングの知識が必要なのか? React
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、三町哲平です。 Ruby on RailsでWebアプリを開発中なのですが、どんなプログラミング言語やフレームワークを使っていてもJavaScriptが絡んできます。 正直な話、HTMLやCSSは分からない部分はその都度調べていけば、よっぽど手の込んだアプリケーションではない限りは素人でもそれなりのクオリティに仕上げれるという感覚があるのですが、JavaScriptが予想以上の難敵なんですよね。 しかも調べていくうちにどうも、フロントエンドだけではなくバックエンドでも使えるらしいじゃないですか...てことは、JavaScript
動機 前回の記事を投稿したことを某SNSで通知したところ、そのSNSでこんなコメントをいただいた。転記する許可を取ったわけでは無いので私なりに要約させていただくと、 なぜそんなトリッキーな書き方をしてまでforを使うのを避けるのか そんな書き方をして可読性を下げるくらいなら素直にforを使う方が良い ということだと理解している。 なるほど、一理ありそうだ。しかし一方で、前回貼ったStackOverflowのQ&Aはなかなかの人気記事(質問に1243ポイント、回答に最大で1559ポイント)なので「多少トリッキーなことをしてでもforを書きたくない!!」という意見をもつプログラマも一定以上いるのだろう。当然私もその1人だ。 ということで、この記事で「なぜそこまで意固地になってまでforを書きたくないのか」を説明することにする。 尚、今回は前回の記事つながりで言語はJavaScriptを使うが、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事に技術的な話はありません。 ただ「プログラミングって楽しいなあ」と実感させてくれたのが、一番嫌いだったJavaScriptだったという話です。 もし、自分にはプログラミングの才能がないと思っている人がいたら、**「それでもプログラミングと一緒に人生を歩けるかもですよ?」**という同じ初心者からの感想をここに残しておきたいと思います。つまり、**爆速で○○ができなかった人間でも「プログラミングを楽しむことは平等に可能」**なのかもと。 ただちょっと、時間と参考書の縁が必要なだけで。 ##はじめに 手短に自己紹介させていただきますが
はじめに 本記事では、constこそが唯一神であることを証明したあと、letを使いがちな場面でいかにしてconstを使うかをまとめていきます。なお、ES2018までの基本構文(reduce, async/await, 配列とオブジェクトのスプレッド構文)を使用します。「いや、reduceとかスプレッド構文とか難しいからlet使うわ」という方のために、便利メソッド詰め合わせであるLodashを使った例もご紹介します。もちろん、Lodashは機能に対してサイズが大きいライブラリであるため、フロントエンド開発でバンドルサイズを軽減したいという方などはLodashの例は無視し、Lodashを使っていない方の例をご参照いただければと思います。 追記:Lodashの使用について 注意事項 この記事は半分ネタで半分本気です。実際の開発でどこまでconst教を導入するかは、他のメンバーと慎重に相談してくだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く