TypeScriptのmoduleSuffixesについて考えて納得した - Qiita
みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri
Reactのベストプラクティスとコード削減パターン - パート1
本記事は React best practices and patterns to reduce code を提供元の事前許可を得たうえで翻訳したものです。 元の記事に従いタイトルに「ベストプラクティス」と含んでいますが、実際にはベストプラクティスは規模や状況によって大きく異なります。 チームの状況にあわせて参考にしていただければと思います。 ===== これは全3パート中の第1パートとなる記事です。 パート1（この記事）パート2パート3 私は数年に渡っていくつかのプロジェクトで、React.jsを使った取り組みに参加してきました。様々なプロジェクトに取り組む中でいくつかの共通するパターンを見出したため本ブログでご紹介いたします。それではいきましょう。 1. reduxのactionsとdispatcherのためにカスタムフックを作成する私はreduxを使うことを好んではいませんが、いくつ
ESLint の設定を ESLint でチェックする
ESLint の設定、見直せてますか？ スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 今回は ESLint の設定を ESLint でテストする という一見奇妙な表題で、 ESLint 設定周りの課題を解決したお話をします。 https://eslint.org/課題感ESLint には標準で多数のルールが組み込まれており、それぞれに詳細なオプションが用意されています。それに加えて、豊富なサードパーティ製のルールや、設定を継承する仕組み(extends) まで揃っているため、設定パターンは無限にあると言っても良いでしょう。 コードベースが小さいうちは、 eslint:recommended のような推奨設定を継承するだけで、すぐにベストプラクティスを実践することができます。 しかし、Vue や TypeScript といった技術構成や、Pretti
JavaScriptの参照レコードとthisバインディング
JavaScriptの仕様には「参照レコード」という概念があります。参照を意識することで、JavaScriptにおけるメソッド呼び出しの理解と左辺式の評価順序の理解を同時に深めることができます。本稿ではこの「参照レコード」の動機と詳細の説明を試みます。 ※ 本記事ではECMAScriptの規格で「参照レコード」と呼ばれている概念を説明します。JavaScriptのオブジェクトは参照渡しのような使い方ができますが、これは本稿で説明する「参照」とは少しだけ異なります。 参照レコードの目的 JavaScriptにおける参照レコードは以下の2つの目的で存在しています。 左辺式の中間評価結果を表現するため。 メソッドのレシーバーを決定するため。 左辺式の中間評価結果とは たとえば a[f()] += 2; というコードを考えます。 function f() { console.log("f()");
Vue.js は Reactivity Transform でさらに進化する
2023 年 1 月 26 日追記 Reactivity Transform は Vue 3.4 でコアから削除されることになりました。 https://twitter.com/danielkelly_io/status/1618256962776600576 ただ完全になくなる訳ではなく、Vue Macros という Vue 向けマクロ集のパッケージが引き継ぐようです。 https://twitter.com/sanxiaozhizi/status/1618290614306746371 Reactivity Transform とは Vue 3.2.25 から experimental で実装されている機能です[1]。script setup の defineProps() などと同様、コンパイラーマクロによってコードを変換する仕組みです。 公式ドキュメントからコードを引用しつつ、主要
JavaScript で parseInt / parseFloat を使わない方が良い理由
となるのが原因です。parseInt というのは、文字列を解析して整数値（int）を返すグローバル関数であり、引数をまず文字列に変換する仕様となっております。その段階で 0.0000005 が "5e-7" という文字列に変換されてしまい、その文字列の先頭の 5 だけが数字として解析されてしまったため、結果として parseInt(0.0000005) === 5 となりました。 なぜ String(0.000005) === "0.000005" に、String(0.0000005) === "5e-7" になるのかについては、この記事の最後で余談として説明します。 整数化には Math.trunc を使おう このように、parseInt は文字列を引数にすることを前提にしているため、速度の面でも可読性の面でも「小数値を整数値に変換したい」という場合に使うのは望ましくありません。最も望
Why does JavaScript's parseInt(0.0000005) print "5"?
I've read an article about JavaScript parseInt, which had this question: parseInt(0.5); // => 0 parseInt(0.05); // => 0 parseInt(0.005); // => 0 parseInt(0.0005); // => 0 parseInt(0.00005); // => 0 parseInt(0.000005); // => 0 parseInt(0.0000005); // => 5 Why is this happening?
JavaScriptの反意図性(クソ挙動)を指摘するバズツイ周辺解説 - Qiita
先日このようなツイートが話題になりましたね 無論この件は例のコインハイブ事件で言われるような反意図性とはずれる話題ですが、直感的ではないという点でうなずくものがあります 今回はなぜこれらがこのような結果になるのか、回避方法等順に説明しようと思います というのも、この中のいくつかはJavaScript固有のものではないので、他人事と思わないようにしていただきたく…… その上でJavaScriptの本当の意味でヤバイ箇所も説明できたらいいなと思います。 ①typeof NaN NaNとはNot a Numberの略、なのになんでnumberなんだ！！ この値は他のオブジェクトを数値に変換する関数parseInt(x)が失敗した場合、0*Infinity等の不確定な計算をした時に出力される値で、エラーを表現する値の一つです。 内部表現的にはただの浮動小数(IEEE754)なので、typeofがn
【Chrome】ServiceWorkerを今度こそ決定的かつ完全に消去する - Qiita
前、Chromeを使うなら、必ずServiceWorkersを無効化しようという記事を書いたのですが、あの方法はてんで全然ダメダメでした。 chrome://serviceworker-internalsには無用なServiceWorkerが増え続け、chrome://flags/からはServiceWorkerの削除設定が削除されました。 そんなわけで、今度こそServiceWorkerを決定的かつ完全に消し去りたいと思います。 といっても自力でどうこうしたわけではなく、全面的に他人の力を借りただけですが。 Reject Service Worker Reject Service Workerをインストールする。 おわり。 かんたん！ 作者はtoshiさんです。 ありがとうございます。 アドオンの技術的内容はServiceWorkerを無効化するという記事に書かれているのですが、Serv
変更に強いコンポーネント設計の方針と規約（Webフロントエンド） - Sansan Tech Blog
技術本部 データ戦略部 Newsグループの木田です。 最近、初めて自作キーボードに挑戦しました。ちょうど２枚目のモニターも買ったので、モニター２台と自作キーボードで快適に記事を書いています。 予めお断りしておきますが、この記事は元々、社内向けに設計方針や規約・ツールなどについて共有するために書いたものでした。最近、他チームの参考資料として役立ったこともあり、社外向けに手を加えて公開する運びとなりました。 はじめに 機構改革・人事異動情報(β) とは ⚛️ Atomic Design に従う ⚛️ Atomic Design とは ⚛️ Molecules と Organisms の分け方 ⚛️ コンポーネントの設計方法 📝 規約 📝 Component と Container を分ける 📝 データの繋ぎ込みは Organisms 以上で行う 💡 Tips 💡 Atoms はタグ本
Ship ESM & CJS in one Package
[[toc]] ESM & CJS ESM - ECMAScript modules CJS - CommonJS In the past decade, due to the lack of a standard module system of JavaScript, CommonJS (a.k.a the require('xxx') and module.exports syntax) has been the way how Node.js and NPM packages work. Until 2015, when ECMAScript modules finally show up as the standard solution, the community start migrating to native ESM gradually. // CJS const cir
プロジェクト内で完結するESLintのローカルルールを作りたい
はじめに ある日、クリーンアーキテクチャで定義した各レイヤーの依存関係が正しいかどうかを ESLint がチェックしてくれると楽だよねという話が出た(今のプロジェクトではこのような構成を取り入れております) ESLint に追加したいルールの要件を整理してみるとわざわざ plugin として公開するほど汎用的なものでもないと思い、プロジェクト内で完結する ESLint の独自ルールを作ってみたというお話 ゴール 下記に示すディレクトリ構成で以下の条件をチェックしたい domains配下のファイルはinfrastructures、adapters, usecases, view-modelsを import しない usecase配下のファイルはinfrastructures、adaptersを import しない view-models配下のファイルはinfrastructures、ad
Deno v1.15で導入されたNode.js互換モードについて
2021/10/12にDeno v1.15がリリースされました。 この記事では、Deno v1.15で新しく導入されたNode.jsの互換モードについて解説します。 Node.jsの互換モードとは？ まず、以下のようなJavaScriptファイルがあったとします。 import { EventEmitter } from "events"; const emitter = new EventEmitter(); emitter.on("foo", () => console.log("foo")); emitter.emit("foo"); $ deno run main.mjs error: Relative import path "events" not prefixed with / or ./ or ../ from "file:///home/uki00a/ghq/github
ユーティリティファーストCSSのススメ〜なぜ、セマンティックなclass命名は失敗するのか？｜菱川拓郎
弊社では全ての新規サイトの構築で、CSSフレームワークをtailwindcssに切り替える意思決定を行い、実際に1年くらいが経過しました。「案件によって、tailwindが向いてそうなものは使う」ではなく「全ての案件で使用」です。使えば使うほどメリットの大きさを感じていますが、同時にtailwindcssの世界観が世間の常識とあまりにも違うため、社内のスタッフには少なからず戸惑いがまだ残っているように思います。 そこで、改めて「なぜtailwindcssを使うと効率的にサイトが構築でき、メンテナンス性が上がるのか」反対に「tailwindcssを使う上で、やってはいけないことは何か」についてまとめたいと思います。 tailwindcssとは tailwindcssとは、2020年11月にバージョン2.0がリリースされたばかりの、今注目のCSSフレームワークです。CSSフレームワークといえば
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
【追記あり】ES2022 Array#at がちょっとおかしい #fix_ecmascript_at - Qiita
既に 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 が丸めないのはたしかに変だということに気づいてしまったので、自
アンサー: named exportは有害なのか - uhyo/blog
こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ
索引:記号とキーワード | TypeScript入門『サバイバルTypeScript』
JavaScriptやTypeScriptのコードには?.のような記号やasのようなキーワードが使われます。こういった記号やキーワードはGoogleで検索しづらく、意味を調べるのは難しいものです。 この索引は、JavaScriptとTypeScriptの記号やキーワードから、その名前や意味を調べられるようにするためのものです。コードを読んでいて未知の記号やキーワードに出くわしたら、その意味や使い方を調べる手がかりにしてください。 ここで扱う記号とキーワードには、JavaScript由来のもの、つまり、JavaScriptとTypeScriptに共通して使えるものと、TypeScriptでのみ使えるものを併記しています。JavaScript由来のものにはのマークを、TypeScript固有のものにはマークを表示しています。 記号! 論理否定演算子 (logical not operator
「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
ハイクラス求人TOPIT記事一覧「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！ 「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！ エンジニアHubでは2019年に「がんばらないTypeScript」を紹介しました。JavaScriptに静的型付けなどを提供するTypeScriptは、今では実プロジェクトに採用されるプログラミング言語になっています。そこで現実的なTypeScriptの設定を、藤吾郎（gfx）さんに解説してもらいました。 2021年の現在、TypeScriptの価値はますます広く認められるところとなり、多くのJavaScriptプロジェクトがTypeScriptで開発されるようになってきました。またT
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
