※スマホ対応はしてません。

カテゴリー: Web

Vue.jsで文字列が空のとき “Mismatching childNodes vs. VNodes” になった。

カテゴリー: JavaScript

Vue.jsで、こんなエラー(というか警告)が出た。

console.error()で &quot:[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content."

[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render.

再現コード

はこんな感じ。

<template>
  <section>
    <p><img />{{text}}</p>
  </section>
</template>

<script>
export default {
  data () {
    return {
      text: '',
    }
  },
}
</script>

たぶん、 <p> の直下には「 <img> 」と「 {{text}} から成るテキストノード」の二つがあるはずなんだけど、文字列が空だとそこにテキストノードが用意されないので、なんか予定と違うぞーと怒ってる感じだろうか。

解決策

とにかくテキストノードが存在していれば良いので、空白文字とか置いておこう。

text: '' を text: ' ' にするとか、同様に <template> の方にスペース追加するとか。

余白が嫌なら幅なしのやつ &zwnj; にしよう。

<template>
  <section>
    <p><img />&zwnj;{{text}}</p>
  </section>
</template>

とっぴんぱらりのぷう。

GitHub PagesをCloudflareでHTTPS化した後にサブドメインを追加する。

カテゴリー: サーバー

ただのメモ。

今回作ったもの(未完成):

前提

もうこれやってる状態。

  • https://ginpei.info/ を、GitHub Pagesで作成、管理、ホスト
  • CloudflareでHTTPS化、キャッシュ

GitHub側

  • 普通のGitHub Pagesの用意
  • CNAME ファイルに clock.ginpei.info とだけ書いて gh-pages ブランチに追加

Cloudflare側

  • 上の方の一覧から “DNS” を開く
  • DNS Recordsに以下の内容で追加
    • CNAME / clock / ginpei.github.io / “Automatic TTL” / ON

おしまい

あとは開くともう動いた。うっひょう簡単!

あんまり詳しくなくて勘でやったら動いたやつなんでアレだったら教えてください。

ヘッダー、フッターの固定にposition:sticky使うとCSSだけで完結するし良いかも。

カテゴリー: CSS

というわけで、いまさら初めて使いました。

デモ

フッターも追加したよ。

使い方

.sticky-header {
  background-color: #fff;
  position: sticky;
  top: 0;
}

position: sticky にして、位置と背景色の指定も併せて行う。背景色がないと見えちゃうから。

position: fixed と違ってサイズ分の余白を自前で用意する必要がないのがらくちん。

利用可能状況

IE以外で使える。大丈夫そうだ。

一通りのウェブブラウザで利用可能。(Can I useより。)

table 関係が現行版だとちょっとまだアレっぽいけど、今回の目的には関係ない。

と思いました

思いつきなので細かいとこ調べてないや許して。スタック文脈とか絡んでくるときっと面倒くさそうな予感がする。

本来は長いコンテンツにたくさんの見出しがあって、みたいな場合に使うものだと思うんだけど、単純に上下端に固定する目的で使うのも悪くないんではないだろうか。だめです?

参考

ES6とES2015に違いはないです。(現代的JavaScriptおれおれアドベントカレンダー2017 – 24日目)

カテゴリー: JavaScript

現代的JavaScriptおれおれアドベントカレンダー2017 – 24日目

昔はES5とかES6とか言ってたはずなのに気付いたらES2015とか呼ばれるようになってて、なんかマリオが64になって急に数字が増えたなあみたいなのに近い感覚だったんですが、そんなことありませんでしたかそうですか。

概要

  • ES6とES2015は同じもの
  • わかりやすいからES2015と呼ぼうぜ
  • ES2015以降は毎年更新
  • 正式名称は “ECMA-262 edition 6” とかそういうの

ES vs JS

JavaScript (JS) はプログラミング言語ですが、その大本の仕様となるのがECMAScript (ES) です。JSはESの一種であり、ESの仕様で定められたものはJSで動きます。(あるいは、動くことが期待される。)

JSは各ブラウザが環境を用意していますが、ESの方はEcma Internationalという団体の中のTC39という委員会が仕様策定を行っています。

ベンダーはESの仕様通りにJSの動作を実装することになります。ES側は、逆にベンダーの提案と先行実装から仕様をまとめてる感じです。(たぶん。ここらへん怪しい。) 二つ以上の実装が存在するまで正式な仕様にはなりません。

ECMAScriptの仕様

ESも、具体的には “ECMA-262” という名前の仕様です。

Ecma International

色々と仕様策定を行ってる団体みたいです。ES以外にもC#とか。

E-C-M-A

前はECMA = European Computer Manufacturers Association(欧州電子計算機工業会)という団体でしたが、なんか国際化した現状に合わせて1994年に名前を変えたそうです。Windows 95より前だ。

なので “ecma” という英単語が存在するわけではないですが、かといって現在は略語というわけでもありません。

ES6 vs ES2015

この二者は同じものを指します。一般には後者の呼び方が推奨されます。

ES6

本来はESの第6版のことです。仕様の正式名称としては “ECMA-262” で、その “Edition 6” と。 class やアロー関数 => 等、「いまどき」の機能が多数追加されました。

前身のES5が2009年の発表で、2011年のES5.1を挟んで久しぶりに、かつ大きく更新されました。その発表年が、2015年です。

ES2015

というわけで、ES6こと “ECMA-262 Edition 6” のことです。

ウェブ界隈の進みが早いのでもっと細かく、毎年仕様を策定していこうという話になりました。それなら連番はわかりづらいよね、と。(ES7, ES8, ES9, ES10, …) そこで連番よりも発行年で、ES6ならES2015と呼ぶことが推奨されるようになりました。

ES2016, ES2017

それぞれ公開されています。

ES2015に比べて影が薄いけど、都度新機能なりが追加されます。

年で呼ぶことを推奨

ESの5、5.1、6版の仕様策定を引っ張ったAllen Wirfs-Brock氏のブログから。

So, why the year-based designation? The 6th edition of ECMA-262 took a long time to develop, arguably 15 years. As ES6 was approaching publication, TC39 (the Technical Committee within Ecma International that develops the ECMAScript specifications) already knew that it wanted to change its process in a way that enabled yearly maintenance updates. That meant a new edition of ECMA-262 every year with a new edition number. After a few years we would be talking about ES6, ES7, ES8, ES9, ES10, ES11, etc. Those numbers quickly loose any context for people who aren’t deeply involved in the standards development process. Who would know if the current standard ES7, or ES8, or ES9? Was some feature introduced in ES6 or ES7? TC39 couldn’t eliminate the actual edition numbers (standards organizations love their document numbers) but it could change the document title. We decide that TC39 would incorporate the year of release into the documents title and to encourage people to use the year when referring to a specific edition. So, the “newest version of JavaScript” is ECMA-262, Edition 8 and its title is ECMAScript 2017 Language Specification. Some people still refer to it as ES8, but the preferred shorthand name is ECMAScript 2017 or just ES2017.

では、何故年ごとの呼称になるのでしょうか。 ECMA-262の第6版は長い時間がかかりました。 15年ですよ。 ES6の公開が近づいていますが、その作業工程を変更し毎年更新することが望まれていると、TC39 (Ecma International内のECMAScript仕様策定の専門委員会)はわかっていました。 そう、毎年新しいECMA-262、そして新しい版番号です。 数年後、私たちは ES6, ES7, ES8, ES9, ES10, ES11, etc. について会話することになります。 標準化作業に明るくない方々にとって、これらの番号はすぐわけがわからないものになってしまうでしょう。 現在の標準がES7なのかES8なのか、それともES9なのか、誰が知っているというのでしょうか。 ある機能が追加されたのはES6? それともES7?  TC39は実際の版番号を消し去ることはできませんでしたが(標準化組織は文書番号が好きなのです)、文書のタイトルを変えることはできました。 TC39は発行年を文書タイトルへ組み込み、また特定の版へ言及する場合はこの年を使うことを推奨することにしました。 ですので、「JavaScript最新版」はECMA-262の第8版であり、そのタイトルはECMAScript 2017 Language Specificationとなります。 (訳注: 2017/08/31当時)  これをES8と呼ぶ人もいますが、簡略化する場合はECMAScript 2017、あるいはただES2017とするのが良いでしょう。

(訳注: “edition number” を日本語で「版次」というらしいんだけど、あんまり一般的じゃなさそうなので「版番号」としました。いやまあおれが知らないだけかもしらんけど。)

そもそもESではなくJSと呼んだ方が

JSはESではありますが、本当にES自体についての文脈でなければJSの名前で呼んだ方が良いだろう、との提言もしておいでです。(前項引用箇所の次の段落。) 同感です。

「現代的なJavaScript」という呼び方

版番号が関係する場合でも、単純に新旧で分けるなら、ES2015以前を「古いJS (legacy JavaScript) 」、以後を「現代的JS (modern JavaScript) 」と呼びましょう、と。

ES2015は大きな変更でしたから、そこで分けるのは妥当だと思います。

まだIE 11(2013年リリース)とか対応しなきゃとかってのはあると思うんだけど、そこはBabelを使う等して、できるだけ現代的な書き方でやっていきたいっすねー。便利だもの。

その他

他のもさー

ついでにIE 9とかIE 11とかじゃなくて、IE2009とかIE2013とか呼びたくない?

あとAndroid 4.4じゃなくてAndroid 2013とか。iOSは……まあいいか。いいか?

おしまい

というわけで「現代的JavaScriptおれおれAdvent Calendar」全24回でした。ここまでお付き合い頂きありがとうございました。

良いお年を!

(でもいくつか触れ損ねた話題もあるので、もうちょっとだけ続くんじゃ。既存記事も少し書き足したりします。)

参考

ジェネレータと自作イテレータで各種オブジェクトもぐーるぐる。(現代的JavaScriptおれおれアドベントカレンダー2017 – 23日目)

カテゴリー: JavaScript

現代的JavaScriptおれおれアドベントカレンダー2017 – 23日目

概要

function* で、イテレータを返すジェネレータ関数を作成できます。中で yield が使えます。

function* createIdGenerator() {
  let currentId = 100;
  while (true) {
    yield currentId++;
  }
}

const iterator = createIdGenerator();
console.log(iterator.next().value);
console.log(iterator.next().value);
console.log(iterator.next().value);

これはオブジェクトを反復可能(イテラブル)にするのに便利です。

const obj = {
  *[Symbol.iterator]() {
    const max = 3;
    for (let i = 0; i < max; i++) {
      yield i;
    }
  }
};

for (let item of obj) {
  console.log(item);
}

イテレータ

著名なデザインパターンのひとつです。配列でないオブジェクトでも、共通のインターフェイスで反復処理を行えるようにします。

JavaScript (ES2015+) では(たぶん一般的な定義とは異なり)イテレータは next() メソッドを持つオブジェクトです。具体的なインターフェイスは後述します。

JavaScriptでのイテレータ

イテラブルなオブジェクトで [Symbol.iterator]() というすごい名前のメソッドを実行すると、イテレータを得られます。

const iterable = new Set([100, 200, 300]);

// イテレータ生成
const it = iterable[Symbol.iterator]();

while (true) {
  // 反復処理を進め、現段階の状態を得る
  const result = it.next();

  // 繰り返し条件を確認
  if (result.done) {
    break;
  }
  
  // 項目取得
  const item = result.value;

  console.log(item);
}

Set オブジェクトはイテラブルなオブジェクトなので、 [Symbol.iterator]() を実行するとイテレータ it を生成して返してくれます。

そのイテレータ it は next() メソッドを持ちます。このメソッド呼び出しを繰り返して反復 (iterate) していきます。

next() メソッドは実行するたびに、なんだろ、結果オブジェクト? result を生成して返します。結果オブジェクトって呼び方で良いかな。 IteratorResult という名前のインターフェイス(後述)を満たすオブジェクトです。

この結果オブジェクトはまた、二つのプロパティを持ちます。 value が反復途中の現段階の値で、 done がもう反復し終えたかが格納される真偽値です。

これらを使って配列でも何でもぐるぐるできます。

for-of で使う

オブジェクトがイテラブルである、つまり前述の各要素を満たす場合、 for-of を使って簡単に反復処理を実現できます。

const iterable = new Set([100, 200, 300]);

for (let item of iterable) {
  console.log(item);
}

わあ短い。

ジェネレータで生成する

[Symbol.iterator]() をちゃんと自作すればどんなオブジェクトでもイテラブルにできます。

next() メソッドを自前で実装しても良いんだけど、面倒なので、ジェネレータ関数というのを使って作ると簡単です。

ジェネレータ

function* を使ってジェネレータ関数を宣言できます。ジェネレータ関数を実行するとジェネレータオブジェクトを得られます。

function* createGenerator() {
  const values = [100, 200, 300];

  for (let i = 0; i < values.length; i++) {
    const item = values[i];
    yield item;
  }
}

const generator = createGenerator();

ジェネレータオブジェクトは加えてイテラブルでもあるで for-of で使えます。わーい。

for (let item of generator) {
  console.log(item);
}

generator[Symbol.iterator]() の結果は元のオブジェクト generator になります。

また同時にイテレータでもあるので next() を持ちます。コードは書かなくても良いかね。

yield

さらっと使ったけど、ジェネレータ関数の中では yield という式を使えます。この式は右辺を value 、また done: false という設定で、 next() で返す IteratorResult オブジェクトを生成します。

必ずしも for 文で使う必要はないです。

function* oneTwoThree() {
  yield 1;
  yield 2;
  yield 3;
}

const it = oneTwoThree();

let result;
result = it.next();
console.log(result.value);  // => 1
result = it.next();
console.log(result.value);  // => 2
result = it.next();
console.log(result.value);  // => 3

[Symbol.iterator]() を実装する

いよいよ [Symbol.iterator]() です。 * を付けて、ジェネレータ関数というかジェネレータメソッドになります。

const obj = {
  *[Symbol.iterator]() {
    const max = 3;
    for (let i = 0; i < max; i++) {
      yield i;
    }
  }
};

for (let item of obj) {
  console.log(item);
}

他のイテレータ生成メソッドを作る

obj じゃなくて obj.iterator() のようにメソッドを呼んでやる必要があるけれど、他の名前でも大丈夫。

目的別に何通りか用意しても良いかもね。

const obj = {
  *iterator() {
    const max = 3;
    for (let i = 0; i < max; i++) {
      yield i;
    }
  }
};

for (let item of obj.iterator()) {
  console.log(item);
}

イテレータのインターフェイス

いっぱい出てきたのでまとめ。

  • 反復可能(イテラブル)なオブジェクト … [Symbol.iterator]() をもつオブジェクト( Iterable )
  • [Symbol.iterator]() … イテレータを返すメソッド
  • イテレータ … next() をもつオブジェクト( Iterator )
  • next()value 、 done を持つオブジェクト( IteratorResult )を返し、内部状態を進めるメソッド
  • value … 反復処理各段階における値
  • done … 反復処理が終了しているかどうか

[Symbol.iterator]()

Symbol.iterator というシンボルが、名前というか何だろ、識別子?になってるメソッドです。 [] は動的にプロパティ名を決めるやつです。別稿参照。あとシンボル Symbol についても。

なんならどこかで Symbol.iterator = 'iterate' とか定義されてると考えてください。

Iterable インターフェイス

オブジェクトがこのインターフェイスを満たしていると、 for-of とか ... とかが使えます。

  • [Symbol.iterator]() … イテレータオブジェクトを返す

Iterator インターフェイス

このインターフェイスを満たすオブジェクトをイテレータオブジェクトと呼びます。

  • next() … イテレータオブジェクトを返す
  • return() (optional) … イテレータオブジェクトを返す
  • throw() (optional) … イテレータオブジェクトを返す

return() を呼び出すと「もう終了するぞ」と、 throw() を呼び出すと「なんかおかしいぞ」を、呼び出し先となるオブジェクトに伝えることが、できる、そう、です。単純に配列みたいな情報を扱う上ではいらなさそうだけど、何か外部から情報を引っ張ってくるようなやつで使うときに便利なんだろか。わかんない。

IteratorResult インターフェイス

next() 他のメソッドはこのインターフェイスを満たすオブジェクトを返す必要があります。

  • done
  • value

分割代入やスプレッド演算子 ...

これら実はイテラブルオブジェクトが対象です。配列じゃなくても自作のオブジェクトでも、 [Symbol.iterator]() を備えていれば使えます。

function* oneTwoThree() {
  yield 1;
  yield 2;
  yield 3;
}

// 分割代入
const [one, two, three] = oneTwoThree();
console.log(one);
console.log(two);
console.log(three);

// スプレッド演算子
function say(one, two, three) {
  console.log(one);
  console.log(two);
  console.log(three);
}
say(...oneTwoThree());

ES2018では普通のオブジェクトも分割代入したりスプレッド演算子で展開したりできるようになるっぽいんだけど、じゃあ普通のオブジェクトも全部イテラブルになるのかな? 仕様策定の様子は追ってないので思っただけだけど。

分割代入と ... の使い方は別稿参照。

その他

[Symbol.iterator]() て何だよ

なんで普通の名前じゃないんだ Symbol なんだ、 toString() みたいにしなかったんだ。

だいたいイテレータはイテラブル

「イテレータ」と「イテラブル」は別インターフェイスなので同時に満たす必要はないんだけど、内部で %IteratorPrototype% というイテレータ共通のプロトタイプがありまして、こいつがイテラブルだったりします。

配列とかのイテレータはこのプロトタイプを継承しているので、JavaScriptネイティブなイテレータはだいたいイテラブルになるっぽい。 TypedArray は専用のものを持たないが、普通の配列 Array の処理を利用している。

ちなみに %IteratorPrototype% の [Symbol.iterator]() は this を返します。

イテラブルではないイテレータ

の例。

class MyIterator {
  constructor(values) {
    this.values = values;
    this.index = 0;
  }

  // 自前で実装するぞ
  next() {
    const value = this.values[this.index];
    this.index += 1;
    return {
      value: value,
      done: this.index >= this.values.length,
    };
  }
};

const values = [100, 200, 300];

// イテレータとして利用
const it = new MyIterator(values);
let result;
result = it.next();
console.log(result.value);

// イテラブルとして利用(できない)
// Exception: TypeError: (new MyIterator(...)) is not iterable
for (let item of new MyIterator(values)) {
  console.log(item);
}

普通のイテレータ

Java方面の話で聞いたときは next() で次に移動しつつ値を戻り値でそのまま得て、続きがあるかどうかは hasNext() という別のメソッドを使うみたいな流れだったと思うんだけど、なんで違うのかしらん。

時代が変わってイテレータパターン自体が変わった?

インターフェイス vs プロトコル

ちなみにMDNだとイテレータとかで「プロトコル (protocol)」という表現が用いられているけれど、仕様書だと「インターフェイス (interface)」です。まあ同じものでしょ。

たしかSwiftはprotocolという表現してたよね。

function と * の間で改行できる

適当に空白文字を置ける様子。

function
* goo() {
}

async はだめだったのに~。

参考

更新履歴

  • 2017/12/23 TypedArray がイテラブルじゃないみたいな勘違いしてたのを修正