なぜ default export を使うべきではないのか？
プロジェクトで使われている技術と ESModule の状況について UIT では、 SPA 開発のプロジェクトにおいて Vue.js と React が多く利用されており、既存の多くは Babel を利用した JavaScript で、新規のプロジェクトでは TypeScript を利用して開発が行われています。 FYI: 【LINE DEV DAY 2019 番外編】UIT Front-end Tooling Survey 2019 技術選定は勿論、プロジェクトにおける細かなコーディングルールについては、プロジェクトのコードオーナーに委ねられており、プロジェクトごとに裁量を持った意思決定を行っています。 その上で、私が携わるプロジェクトにおいては、 default export を可能な限り避けるように心がけています。 import 側の裁量で対象を自由に命名できてしまう 今回は「『Da
Dynamic import() · V8
Dynamic import() introduces a new function-like form of import that unlocks new capabilities compared to static import. This article compares the two and gives an overview of what’s new. Static import (recap) #Chrome 61 shipped with support for the ES2015 import statement within modules. Consider the following module, located at ./utils.mjs: // Default export export default () => { console.log('Hi
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
import-js で JavaScript の import を自動入力する - Qiita
React 等、新しい ES 環境で import を多用する開発を行ってると、クラスや関数を使う度、import に毎回追加、というのが面倒じゃないですか？私はめっちゃ面倒くさかったです。 そんなとき、import-js を使うと、足りない import 文を入力してくれて大変便利です。 https://github.com/Galooshi/import-js fix import で足りない import 文を勝手にプロジェクトのルートや node_modules から探していい感じに入れてくれます。また同じ名前のモジュールが複数ある場合、ダイアログを出してくれます。 また JSX や flow にも対応しているため、<ComponentName /> みたいな JSX タグも import 文に追加してくれます。 エディタも、Atom, Emacs, Sublime, Vim 用の
linkのrelの種類と効能等
linkのrelの種類と効能等 Web Componentsの流れでHTMLImportsをよく見るようになったり、パフォーマンス周りでプリフェッチ系の属性が<link>で指定するようになったりしている今日この頃。気になったのでW3Cの Links in HTML documents を眺めたメモ。 Links in HTML documents そもそもリンクとは一体何なのか？ Webにおけるリンクは、<a>と<link>の2種類がある。それらには、 Webのあらゆるリソースの場所 を示す役割が与えられている。つまり、hrefで指定しているURLがそれにあたる。そのURLの振る舞いの種類については、relやrevで記述する、と。revって削除されるんだっけ？ <img>や<form>といったように、リソースへのリンクはその他のHTML要素でも行う。が、<link>についてはドキュメントの
@importの文法 - Weblog - Hail2u.net
@importでは何の気なしにurl()を使わず書いていたんだけど、どんな時もそれで良いのかよく知らなかった。どうやら文字列で書くとそれをurl()で括ったように解釈してくれると仕様で決められているようだ。 ということで以下の7パターンはすべて同じように解釈される。 @import url(foo.css); @import url("foo.css"); @import url('foo.css'); @import "foo.css"; @import 'foo.css'; @import"foo.css"; @import'foo.css'; CSSWringではurl()を外して二重引用符に統一し、直後の空白を削除することにした。 @import絡みではもうひとつちょっとよくわからないところがあって、@importだけのCSSの場合に最後のセミコロンが必要なのかどうかという点。現状
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
