Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに 初投稿です。 知ってたら便利になる小技が無かったのでまとめました。 「小技が知りたい...だけど検索しても出てこない...!」 そういう時に役立ちます。 比較的古いバージョンのJSでは一部の小技が使えないかもしれません。 随時追加予定です。他に小技をご存じの方はコメント欄にGO。 おことわり この記事は、あくまで"こんなやり方もあるよ"と紹介しているだけなので、何でもかんでもこれらの小技を使うと、かえってコードの可読性を下げる可能性があります。コードサイズと可読性を天秤にかけてどちらが良いかを都度確認しましょう。 記事内の間違った部分の指摘等はこの記事のコメントや編集リクエストでして下さい。 当方コードゴルファーなので、バイト数短縮小技も入れていることをご了承ください(一応該当する節には*をつけています)。 配列 配列の重複した値を削除1 const meta = ["foo",
追記: 10/11 ハテブでバズっているようで、色々指摘があったので追記 getElement*は動作が早いのでIDやクラス名が自明の場合はgetElement*を使う方がいいと言う意見もあり、また、ページの表示で大量に呼び出されるわけではないからボトルネックにはならないと言う意見もある。 getElement*で返されるオブジェクトは動的な変化に対応しており、querySelector*は動的な変化に対応していないため、場合によってはgetElement*を使うといい。このサイトで遊んでみよう。 https://ja.javascript.info/searching-elements-dom#ref-263 for await ... ofは非推奨なので Promise.allを現代的な書き方にした 顧客先のブラウザが古い場合も考慮して、あえてレガシーな書き方もする場合があるらしい。現
はじめに promiseを使うとき、いつもpromiseメソッドチェーンで記載していますか? async/awaitを利用していますか? もちろん状況によって両方書くのが殆どだとは思うのですが、私はasync/awaitの方が同期的な書き方ゆえに読みやすいため、なるべくそちらで記載しています。しかしながら、エラーハンドリングが理解できていなかったため、エラーの所在を突き止めるのに苦労してしまいました。 そのため、これを機にasync/awaitにおけるエラーハンドリングについて備忘録的にまとめておきます。 この記事のまとめ; catchされるエラーはrejectのみか、throwされたエラーも含まれるか →両方catchできる async関数における処理の順序、awaitがある場合とない場合 →awaitがない場合には同期的に処理が実行され、catchできなくなる エラー処理を外側に伝播し
setTimeout は、指定された時間以降に指定されたコードを実行する JavaScript の API です。ブラウザでも Node.js でも広く使われているのですが、実装はまちまちで、色々と特殊な条件も多く、挙動を完璧に理解している人は少ないと思います。この記事では、そんな setTimeout を可能な限り深堀りしてみようと思います。 先に書いておきますが、ものすごくニッチで細かい話ばかり並びます。突然私が、ただ純粋に setTimeout について調べたくなったので、その結果をまとめただけのものです。普通に開発している人には必要のない情報が多くなるでしょう。この記事は基礎から setTimeout を学ぼう、という方には全然向かないと思います。 また、JavaScript のイベントループについてある程度理解していることを前提とします。その詳しい理解には、@PADAone さん
この記事について JavaScriptはお好きですか? Reactなどフロンドエンドを中心に人気の言語なので、触ってる人はたくさんいると思います。 奥深くて自分も好きな言語ですが、結構なんとなくで触っていたりしませんか? 今回は自分が後輩によく聞かれた事や、自分が引っかかった事をたくさん書いていきます。 つまり基本的には初心者向け、よくても中級者向けです。 何か一個でも知らない事があれば御の字のつもりで書いたので、ぜひ気軽に読んでください! JavaScript編 略称はJS、Javaダメぜったい いなさそうなのに稀にいるという・・ Web開発から入ってプログラムを広く知らない場合に発生しやすい? Javaは全く別に王者がいるので、万が一使っていたららやめましょう。 略称は JS(じぇーえす) でお願いします。 データ型、Object Objectはキーと値をいくつも持てるJSのデータ型で
JavaScriptのデバッグは、ウェブ開発の必須スキルのひとつです。プログラムの実行をデバッグすることで、現在の変数の値や、処理がどのように進んでいるのかを確認できます。デバッグによってプログラムが意図した動作になっているかの分析に役立てられます。 本記事ではChrome・Edgeブラウザーの「Developer Tools」(以下「デベロッパーツール」、「DevToolsデブ・ツールズ」という略称もあります)を使用してJavaScriptをデバッグする際の基本的な使い方を解説します。「今までデベロッパーツールを使ったことのない」という方でもこの記事を読めば理解できるよう、チュートリアル形式になっています。20分ほどで理解できるようまとめているので、順番に試しながら読み進めてください。 この記事で学べること デベロッパーツールの使い方 JavaScriptのブレークポイントの使い方 実行
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方、既
数列の和を求めるプログラムを作成することになり、意気揚々と以下のようなプログラムを書いたという状況を想像して下さい。 function sum(nums, acc = 0) { if (nums.length === 0) return 0; if (nums.length === 1) return nums[0]; return sum(nums.slice(1), acc + nums[0]); } const nums = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; console.log(sum(nums)); // expected: 55 一見すると何も問題なさそうに見えるプログラムですが、実はバグがあります (皆さん分かりますか?) *1。実際に上記プログラムを実行すると 55 ではなく 10 が出力されます。 こうした場面に遭遇すると、自然と sum
を読んで思い出したのでご紹介です。 元の記事と同様に以下の関数 sum について、 function sum(nums, acc = 0) { console.log({ nums, acc }); if (nums.length === 0) return 0; if (nums.length === 1) return nums[0]; return sum(nums.slice(1), acc + nums[0]); } この関数sumの引数 (nums と acc) の呼び出しごとの変化を見たい場合は、所謂プリントデバッグや debugger を使うのは一般的なテクニックとしてよく知られていますが、このような関数呼び出し時の引数を知りたい場合はmonitor(function)という関数を使うことで同様の効果を得ることが出来ます。 この場合は monitor(sum)とした後に、関
2021年になってJavaScript、TypeScript、Node.jsの勉強を始めました。 この記事では、読んで良かった本、記事、公式ドキュメントなどをまとめていきます。 ※2021/03時点の情報です。 個人的なリンク集ですが、「これも読むと良いよ」というものがあればぜひ教えてください。 ECMAScript ECMAScriptの仕様は、EcmaのTC39で策定されている Ecma TC39 GitHub organization ep78 TC39 | mozaic.fm Node.jsの各バージョンでのECMAScriptサポート状況 JavaScript Misreading Chat - #86: JavaScript: the first 20 years JavaScript 二十年の歴史についての回 JavaScript チュートリアル | MDN JavaScri
JSer.infoは2011年1月16日に公開したJavaScriptの情報サイトで、2021年1月16日で公開してからちょうど10年です。 JSer.infoでは、10年間で10201サイト紹介し、522コの記事書いてきました。 JSer.infoの紹介したサイト数(累計)。ソース 10年間途切れることなく毎週更新していて、月別の記事数は毎年同じ推移です。 JSer.infoの月別の記事数。ソース この記事では、10年間やってきたJSer.infoの目的を振り返り、 JavaScriptの情報の集め方、書き方、まとめ方について書いていきたいと思います。 ⚠️ すべてを書いているのでものすごく長いです。 この記事やJSer.infoに関する意見や感想などは、次の場所に書いてください。 この記事をTweetする Twitter: #jserinfo GitHub Issue: JSer.in
まとめ async/await 構文は、Promise で書ける処理のうち特定のケースしか表現できない 特定のケースとは、ある非同期処理の前処理と後処理がそれぞれ 1 個ずつの場合のみである async/await 構文は初心者に非同期処理を導入する際に適しているが、非同期処理を逐次処理として書けるという幻想を与えるので、どこかで知識をアップデートする機会を設けるべきである この記事はなに? 少しバズったのでまとめておこうかと。 「async/await があれば Promise なんて難しいものは要らない!」とか言ってるウブな子に、複数の API に並列にリクエストを投げて一つ以上成功した時だけ先に進む、みたいな問題を与えて愛でてみたい。— Yuta Okamoto (@okapies) 2020年12月11日 async/await は Promise のネストを手続き的なコードに見え
ブラウザで長いループや、重い処理をともなうループを回したいとき、同期的にJavaScriptを実行するとメインスレッドがブロックしてしまうので、ちょっとずつ細切れに分割して実行したい、ということがある。 昨日久しぶりに書いたら新たなパターンと出会ったので、これまでにどう書いてて今回どうなったかメモ。 setTimeoutする 以前(10年前とか)はこんなのをよく書いていた。 itemsがでかいArrayで、console.logがすごく重い処理だとして読んでください。 function iterateHeavyTask(items) { const startAt = new Date(); while (items.length > 0 && new Date().getTime() - startAt < 10) { console.log(items.shift()); } if (
JavaScriptの非同期処理Promise、AsyncとAwaitの仕組みをGIFアニメで解説した記事を紹介します。 ⭐️🎀 JavaScript Visualized: Promises & Async/Await by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに コールバック地獄 Promiseの構文 イベントループ: Microtasksと(Macro)tasks AsyncとAwait はじめに JavaScriptのコードが期待通りに実行されないことに悩まされたことはないですか? おそらく、関数が不規則に実行されたり、予測できないタイミングで実行されたり、実行が遅れたりしたことがあるかもしれません。そして、ES6で導入された新機能Promiseが原因かもしれません! 何年も
setTimeout(() => console.log(5), 1000); setTimeout(() => console.log(4), 1000); setTimeout(() => console.log(3), 1000); setTimeout(() => console.log(2), 1000); setTimeout(() => console.log(1), 1000); setTimeout(() => console.log(0), 1000); よめ太郎「↑このコードを実行するのに、合計で何秒かかると思う?」 娘「ええと、setTimeout()は確か」 娘「タイマーをセットするメソッドだから」 娘「1,000ミリ秒後・・・つまり1秒後にconsole.log(5)が実行されるよね」 よめ太郎「せやな」 娘「その後、次の行が処理されるから」 娘「また1秒経過し
この3つの原則は書籍の構成にも現れています。 第一部の基本文法で「書き方」を学び、第二部のユースケースで「作り方」を学べるようになっています。 「学び方」は、章としてではなく全体的な流れとして取り入れることにしました。 なぜなら、「学び方」自体は学びたいことによっても異なる方法を取る場合があります。 そのため、「学び方」で個別の章とするよりは、他の章で「書き方」や「作り方」と一緒に見たほうがよいと考えたためです。 たとえば、基本文法などの学び方にはMDNのようなリファレンスサイトを見たほうがいいし、 アプリケーションの作り方は実際のサイトなどを参考にしたほうがよいためです。 第一部と第二部がどのように書かれたのかをざっくりと振りかえってみます。 第一部: 基本文法 第一部: 基本文法はJavaScriptの基本的な文法について扱っています。 プログラミングの入門書で文法については避けること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く