なすびブログ

iOS10のSafariではVideo要素のインライン再生が可能になった

iOS9までのSafariでは、基本的にvideoのインライン再生はできず、再生すると強制的にフルスクリーンになっていました。

iOS10からはvideo要素にplaysinline属性をつけてあげることでインライン再生が可能になってます。

<video src="path/to/video.mp4" controls playsinline></video>

※ただしiOS9でもWebViewでは webkit-playsinline でインライン再生できました。

そしてこの仕様に併せて、JSからvideoのフルスクリーン制御もできるようになってます。

const video = document.querySelector('video');

// フルスクリーンにする
if(video.webkitSupportsFullscreen){
  video.webkitEnterFullscreen();
}

// フルスクリーンから離脱する
if(video.webkitSupportsFullscreen){
  video.webkitExitFullscreen();
}

video以外の要素で webkitRequestFullscreen を使ってフルスクリーンするのはまだiOSでは解禁されていませんが、videoのみ webkitEnterFullscreen でフルスクリーンできるようになった、ということです

HHVMではv3.19以降でないと定数に配列を使えない

HHVMはPHPとある程度互換性がありますが、完全互換ではありません。

const ARR = ['foo', 'bar'];
var_dump(ARR);

このような定数に配列を代入すると、Fatal errorを吐いてしまいます。これはクラス定数も同じです。
HHVMを3.19以降では機能がサポートされているので利用可能です。

Frontend de KANPAI! でLT登壇します

DeNAのデザイン戦略室が主催するイベント「Frontend de KANPAI!」に菅沼がLTで登壇致します。

フロントエンドに関わる人の情報交換と交流を目的としているイベントで、お酒とおつまみの提供もあるので興味のある方は気軽にご参加ください！

https://frokan.connpass.com/event/57554/

SSRしないNuxt.jsでページロード時に非同期部分を更新する方法

Nuxt.jsでは、外部サーバ等から非同期でデータを取得・表示する場合にも asyncData を使ってあげることでクライアントサイドはもちろん、サーバサイドでもデータを取得し、HTMLで出力することが出来ます。

SSRできる本番環境があれば何の問題もないのですが、SSRせずプリレンダリングのみで運用する場合には、 asyncData は静的ファイルをgenerateした時点でしか走っておらず、ページロード時にデータが更新されていない問題が起こり得ます。

例えばコーポレートサイト等で、別のサーバにWordPressが設置してあり、トップページのお知らせとしてWordPressから記事を取得するような場合を想定すると、こんな感じで作ってあげることで解決できます

// 非同期でデータを取ってくる関数
async function getPostData() {
  return { data } = await axios.get('https://blog.example.com/wp-json/wp/v2/posts');
}

export default {
  async asyncData(context) {
    const obj = {};
    if (context.isServer) { // asyncDataするのはサーバサイド（プリレンダリング時）のみ
      obj.posts = await getPostData();
    }
    return obj;
  },
  async created() {
    if (!this.$isServer) { // クライアントサイドはここで更新をかける
      this.posts = await getPostData();
    }
  },
};

要は asyncData を使うのはサーバサイド（プリレンダリング時）のみ。
クライアントサイドでは created でデータの更新をかけてあげるわけです。

こうすることでプリレンダリング運用でも、一応（少し古いかもしれないけど）非同期データのHTMLもプリレンダリングされていて、ブラウザで訪れた際にはちゃんと最新の情報に更新されます。

PhpStormでnode製サイトのプレビューをする

node製サイトを開発時はwebpackを利用していればwebpack-dev-serverなどを利用するのが常ですが、プロダクションビルド後のファイルで確認したい場合もあります。

そういうときにわざわざサーバーにアップロードしたり、MAMPなどを利用するのは面倒です。ですが、PhpStormであればビルドも含めてショートカット1発でサーバーを起動することができます！

今日はその設定をしていきましょう。設定は1分で終わります。

Step.1 サーバー設定

「Run」->「Edit Configurations」から「Run/Dubug Configurations」のウィンドウを表示し下記に設定します。

Name: Preview server（好きな名前を設定してください）
Single instance only: チェックを入れる（重複起動を許可しないかのチェックです）
Host: localhost
Port: 3001
Document Root: ドキュメントルートへのパス

HostとPortは他のアプリケーションが利用中だと起動できないので、webpack-dev-serverやMAMPなどを利用している場合は被らないように設定するのが吉です。

Step.2 npmスクリプトの起動設定

次に「Before launch: Acvtive tool window」で「+」をクリックして「Run npm script」をクリックします。

すると「NPM Script」のウィンドウが開くので下記に設定します。

Command: run
Scripts: build（など自分でpackage.jsonに設定したスクリプト名）

Step.3 起動

あとは^ Rまたは「Run」->「Run 'Preview server'（上記のName:で設定した名前）」をクリックすれば指定したHostとPortでサーバーが起動します。

PhpStormなどJetBrains製のIDEはWeb関係の技術と親和性が高いので、Web開発者は必携ですね。

Vue.jsでSSRする場合にv-forでエラーが出る

Nuxt.jsを含めて、Vue.jsの2.xを使ってSSR（サーバーサイドレンダリング）をする場合に、 v-for の箇所で下記のようなエラーが出る場合がある。

The client-side rendered virtual DOM tree is not matching server-rendered content.

再現したコードはこれ（ items は単純な文字列の配列）。
ちなみにVue.jsのバージョンは 2.2.6

<template v-for="item in items">
  {{ item }}
</template>

回避するには、下記のように個々を要素で囲ってあげる。

<template v-for="item in items">
  <span>{{ item }}</span>
</template>

クライアントサイドのみではエラーは出ず、ちゃんとレンダリングされるので、サーバ側の実行ロジックにバグがあるのかもしれない。

WP REST API では1回のリクエストでカテゴリーを全件取得することはできない

タイトルの通りですが、WP REST APIでカテゴリー情報を取得する場合、下記のエンドポイントを使いますよね。

/wp-json/wp/v2/categories

これに対してパラメータ per_page で取得件数を設定できるのですが、実はこのパラメータ、1〜100の数値以外を渡すとエラーになります。

ドキュメントにも取りうる値の範囲は記載されていません
https://developer.wordpress.org/rest-api/reference/categories/

なんとなく語感がget_postsでよく使う posts_per_page に似てるので-1を指定すれば全件取得できそうな気がするのですが、ところがどっこいできません。

おそらくパフォーマンスの問題で無茶な使い方を塞がれてるんだと思うのですが、100件以上になりうる可能性がある場合は、本当に必要なカテゴリーだけをパラメータ include で指定して取得してあげるほうが良さそうです。

それでも100件以上欲しい場合は、パラメータ page でしっかりロジカルにページングする必要がありそうです。

PHPでMarkdownをいい感じにやる

Markdown方言

Markdownの方言は
Markdown
CommonMark
Github flavored Markdown
Markdown Extra
だいたいこの4つから選ぶことになると思います。

CommonMark

Markdown系のスタンダード（になるかもしれない）
現在も仕様策定中で2017年内にv1.0.0がリリース予定
公式のPHPの実装がある

Markdown

本来の「Markdown」といった場合はこのMarkdown
機能は少ない
実装はいくつかある

Github flavored Markdown

Githubで利用できるMarkdown
URLの自動リンクやテーブルが利用可能
行末にスペース2つを入れずに、改行するだけで<br>が生成されるのが特徴
PHPでの実装は単独では見つからない

Markdown Extra

テーブルに加え定義リスト（まさにこのリストの部分）が利用可能
多機能で実装も多い
PHPで実装されている

ライブラリ

今回はcebe/markdownを選びました。

cebe/markdownの特徴はMarkdown・Github flavored Markdown・Markdown Extraの3つが利用可能ですが、Markdown Extraについては定義リストなど実装されていない文法があるようです。
ただし、拡張が簡単なので、今回はこれを利用します。

実装

まずはcomposerでインストールします。

composer require cebe/markdown

下記のコードで簡単にHTMLに変換することができます。

$markdown_string = '# Hello, Markdown';
$converter = new \cebe\markdown\MarkdownExtra();
echo $converter->parse($markdown_string);

<h1># Hello, Markdown</h1>

ただ、Markdown Extraは改行のみだと<br>が生成されず、行末にスペースを2つ入れる必要があるので、拡張してみましょう。

class MyMarkdown extends \cebe\markdown\MarkdownExtra{
	//同ライブラリのGithub flavored用の実装と同一
	protected function renderText($text){
		if ($this->enableNewlines) {
			$br = $this->html5 ? "<br>\n" : "<br />\n";
			return strtr($text[1], ["  \n" => $br, "\n" => $br]);
		} else {
			return parent::renderText($text);
		}
	}
}

$markdown_string = '# Hello, Markdown';
$converter = new MyMarkdown();
echo $converter->parse($markdown_string);

簡単ですね。これをうまく利用するとWordPressでも実装することができます。
WordPressへの組み込みはまたいずれ…。

Prerender SPA Plugin を使ってSPAサイトのSEO対策をする

株式会社なすびのウェブサイトは、Vue.jsを用いたSPAで作られています（2017年4月現在）。

コーポレートサイトのような情報の提供に重きを置くサイトで、SPAのアーキテクチャを使うことはSEOの面からあまり適した用途であるとは言えません。

それは、GoogleボットこそJSを実行してからパースしてくれるので問題にはならないのですが、FacebookなどのSNSにシェアされた場合は未だにJSの実行までしてくれないからです。

これを解決するためには、サーバーからのレスポンスでHTMLを返す必要性が絶対的にあるのですが、いかんせんSSRを前提に環境の構築を考えると、サーバサイドでNode.jsを噛ませる必要があったりなど、なかなかに敷居が高いのです。

しかしコーポレートサイトのような、ページ数も動的コンテンツも少ない小規模サイトであれば、プリレンダリングという選択肢もあります。

今回はwebpackプラグインでサクッとプリレンダリングする方法の紹介です。

Prerender SPA Plugin
https://github.com/chrisvfritz/prerender-spa-plugin

このプラグインを使って、webpackのbuild過程で静的HTMLを書き出してしまいます。

// webpack.conf.js
var Path = require('path')
var PrerenderSpaPlugin = require('prerender-spa-plugin')

module.exports = {
  // ...
  plugins: [
    new PrerenderSpaPlugin(
      // Absolute path to compiled SPA
      Path.join(__dirname, '../dist'),
      // List of routes to prerender
      [ '/', '/about', '/contact' ]
    )
  ]
}

上記のように保存先とエンドポイントを設定してbuildすると、下記３ファイルが書き出されます。

/index.html
/about/index.html
/contact/index.html

これらのファイルをウェブサーバーに配置すると、当然下記URLでbuildされたHTMLがレスポンスされるのですが、

http://example.com/
http://example.com/about/
http://example.com/contact/

SPAとしてリンクを辿ってaboutページに遷移すると、URLは /about となります。

/about と /about/ は違うファイルを指しているため、この状態でリロードすると404になってしまいます。
これを回避するためには、 /about にリクエストが来たら /about/ へリダイレクトする.htaccessを置いてあげれば良いのです

<ifModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !index
RewriteCond %{REQUEST_URI} !.*\.(css|js|html|png|jpg)
RewriteRule (.*) / [L]
</ifModule>

Hello nasbi!

フロントエンドのウェブ制作会社なすびのブログを始めます。

主に制作過程においてスタッフが躓いた点や日々の気付きを投稿していきます。