Google Chrome の 開発者ツールの使い方

https://developers.google.com/web/tools/chrome-devtools/?utm_source=dcc&utm_medium=redirect&utm_campaign=2016q3

Mobile Mode

https://developers.google.com/web/tools/chrome-devtools/device-mode/emulate-mobile-viewports

モバイルモードにした際に、右上のメニューから追加で様々な設定が可能。

デバイス風

メディアクエリの分岐点

クリックすると、その幅になってチェックもできる。

ルーラー

位置情報とデバイスの傾き

https://developers.google.com/web/tools/chrome-devtools/device-mode/device-input-and-sensors

CSS DOM 周り

https://developers.google.com/web/tools/chrome-devtools/css/

いつも使っているものなので省略。

Console

https://developers.google.com/web/tools/chrome-devtools/console/

コンソールの内容を消す

  • Right-click in the Console and press Clear console.
  • Type clear() in the Console.
  • Call console.clear() from within your JavaScript code.
  • Type Ctrl+L (Mac, Windows, Linux).

履歴をブラウザをリフレッシュしても残す

コンソールメッセージを右クリックで開いて保存できる。

log をグループ化

var user = “jsmith”, authenticated = false;
console.group(“Authentication phase”);
console.log(“Authenticating user ‘%s'”, user);
// authentication code here…
if (!authenticated) {
console.log(“User ‘%s’ not authenticated.”, user)
}
console.groupEnd();

階層化もできる

var user = "jsmith", authenticated = true, authorized = true;
// Top-level group
console.group("Authenticating user '%s'", user);
if (authenticated) {
    console.log("User '%s' was authenticated", user);
    // Start nested group
    console.group("Authorizing user '%s'", user);
    if (authorized) {
        console.log("User '%s' was authorized.", user);
    }
    // End nested group
    console.groupEnd();
}
// End top-level group
console.groupEnd();
console.log("A group-less log trace.");

groupEnd した時に表示

console.groupCollapsed("Authenticating user '%s'", user);
if (authenticated) {
    ...
}
console.groupEnd();

条件によって表示を分岐

first argument が true の時だけ実行。

console.assert(list.childNodes.length <= 500, "Node count is > 500");

 

すごいフロントエンドエンジニアになるために Kotlin を始める

最近やっと気づいたのですが、すごいフロントエンドエンジニアは、もともと JS ではない、もっとしっかりした言語の経験がある方が多い。Java でバックエンドを書いていたとか、デスクトップアプリケーションを作っていたとか、ActionScipt で Flash を書いていたとか…

そういった言語を通じて、型とかコンパイルとか、オブジェクト指向とか、モジュール分割とか、alt JS が後から取り込んだ機能に触れているんだと思うんです。

自分は完全に HTML, CSS, JavaScript といったフロントの技術しかやってこなかったので (あとは趣味のプロジェクトで Wordprss, PHP を少し書くくらい)、そのあたりの感覚がない。これでは追いつけない。

ということで、Kotlin をやってみることにしました。React Native を触りだしてネイティブにも興味が出てきたし、そしてやっぱり Kotlin / Swift がわかってないと React Native をうまく使えない部分がたくさんある、ということもあって、Java の後継的な存在の Kotlin をやってみることにしました。

Android Studio をインストール

https://kotlinlang.org/docs/tutorials/kotlin-android.html

最新版 3.0 の Android Studio にはすでに kotlin が入っていることなのでこれをインストール。

kotlin サポートにチェックを入れれば良い的なことが書いてあるので入れる。

プロジェクトをそのあと作る。

cmmd + shift + A で Find Action から Convert Java File to Kotlin File をみつけて実行。これで Java を Kotlin に変換しているとのことだが、よくわからない。

すると kotlin の config がまだされていないとか、gradle のシンクがされていないとか警告が出るとのことだが、出ない。よくわからない。されているということだろう。

Building and publishing the Kotlin application for Android

You are now ready to build the application and run it on an emulator or device. This works in exactly the same way as in Java. You can make a release of the application and sign it similarly to what you do for an Android application written in Java.

アプリケーションをビルドし、エミュレーターやデバイスで走らせる準備ができました。Java と全く同じ方法で可能です。アプリケーションのリリースや sign は Java で書かれたアンドロイドアプリケーションと同じようにして可能です。

と書いてあるが、Java でやったことがないから、わからない!

ラーニング用の公式プラグインがある

後でやってみようと思う。

https://kotlinlang.org/docs/tutorials/edu-tools-learner.html

Google のやつをみつけた

https://codelabs.developers.google.com/codelabs/build-your-first-android-app-kotlin/index.html?index=..%2F..%2Findex#1

URL からいって多分 Google 公式のチュートリアルをみつけたのでやってみる。

Java が入っていなければ指示に従って入れる。

Set JAVA_HOME

JAVA_HOME がなんなのかよくわからないが、指示に従う。

Set JAVA_HOME to the installation location:

  1. Open Terminal. ターミナルを開く
  2. Navigate to your home directory using cd cd でホームディレクトリに移動
  3. Open the file ~/.bash_profile which is a configuration file for your terminal ターミナルの設定ファイルである~/.bash_profile を開く。
  4. Add the following command to the file: 次のコマンドをファイルに追加する。
    export JAVA_HOME=$(/usr/libexec/java_home)
  5. Reload the configuration file using: 設定ファイルをリロード
    source ~/.bash_profile
  6. Enter echo $JAVA_HOME to confirm the path. 左記コマンドで path を確認。

最初のプロジェクトを作る

https://codelabs.developers.google.com/codelabs/build-your-first-android-app-kotlin/index.html?index=..%2F..%2Findex#2

After these steps, Android Studio:

上記の段階を通じて、アンドロイドスタジオは以下のことをしてくれます。

  • Creates a folder for your Android Studio project. This is usually in a folder called AndroidStudioProjects.
  • Android Studio プロジェクト用のフォルダを作成します。通常は AndroidStudioProjects という名前のフォルダの中に作られます。
  • Builds your project (this may take a few moments). Android Studio uses Gradle as its build system.
  • プロジェクトをビルドします。(少しだけ時間がかかります) Android Studio は Gradle をビルドシステムとして用います。(なるほど Gradle はビルドの時に使うシステムのことか)
  • Opens the code editor showing your project.

シミュレーターを立ち上げる

あとはひたすら言われた通りにやっていったら、シミュレーターが立ち上がる。立ち上げる際に眺めに Google アイコンが画面に出ているが、トラブルではないので安心ください。少し待つと起動します。

いやー簡単だ!

次は layout エディターだ。

引き続きこれやっていく。

https://codelabs.developers.google.com/codelabs/build-your-first-android-app-kotlin/index.html?index=..%2F..%2Findex#3

React Native ドキュメントの日本語訳

よりみやすい形でこちらで翻訳を継続しています。

https://nakanisi-yusuke.gitbooks.io/react-native-document-translate-japanese/content/

React Native

Learn once, write anywhere: Build mobile apps with React

一度学べば、どんなところでもそれを書くことが出来る:モバイル・アプリケーションを React で構築する

ネイティブ・モバイル・アプリを JavaScript と React で構築する

Build native mobile apps using JavaScript and React

React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.

React Native を用いることで、JavaScript だけでモバイル・アプリケーションを構築することができます。React Native は React と同じ構造を使用しており、宣言的に定義した Component を用いて、上質なモバイル UI を構成することができます。

React Native アプリは、本当の モバイル・アプリケーションです

A React Native app is a real mobile app

With React Native, you don’t build a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React.

React Native で作成するのは「モバイル・ウェブ・アプリ」でも「HTML5 アプリ」でも「ハイブリッド・アプリ」でもありません。作成するのは、Objective-C や Java を用いて作成したアプリケーションと、未分けがつかない、本当のモバイル・アプリです。React Native は、通常の iOS や Android のアプリケーションと同じ基本的な UI ブロックを用います。これらの UI ブロックを JavaScript と React の中に組み込みます。

再コンパイルに時間を浪費するのはやめにしましょう

Don’t waste time recompiling

React Native lets you build your app faster. Instead of recompiling, you can reload your app instantly. With Hot Reloading, you can even run new code while retaining your application state. Give it a try – it’s a magical experience.

React Native を使えば、以前より早くアプリを構築することができます。React Native では、再コンパイルをするのではなく、アプリケーションを即リロードさせることができます。Hot Reloading によって、変更を加えた新しいコードを、アプリケーションの状態を保持したまま、実行することができます。試してみてください。魔法のような体験です。

必要な時にネイティブ・コードを使用することもできます

Use native code when you need to

React Native combines smoothly with components written in Objective-C, Java, or Swift. It’s simple to drop down to native code if you need to optimize a few aspects of your application. It’s also easy to build part of your app in React Native, and part of your app using native code directly – that’s how the Facebook app works.

React Native はスムーズに、Objective-C や Java や Swift で書かれたコンポーネントを取り込むことができます。アプリのいくつかの側面を最適化するために、ネイティブ・コードを使用する方法は非常に簡潔です。またアプリの一部に React Native を用い、一部にネイティブ・コードを直に使うことも簡単です。Facebook アプリケーションもそのようにして動作しています。

React Native を始めましょう

Get Started with React Native

Who’s using React Native?

Thousands of apps are using React Native, from established Fortune 500 companies to hot new startups. If you’re curious to see what can be accomplished with React Native, check out these apps!

何千ものアプリケーションが React Native を使用しています。その範囲は広く、既に評価が安定した Fortune 500 カンパニーから、今まさに動いている新規スタートアップでも使用されています。

Getting Started

This page will help you install and build your first React Native app. If you already have React Native installed, you can skip ahead to the Tutorial.

このページは初めて React Native をインストールして、アプリケーションを作る人のための情報を提供します。すでにインストールしているひとは飛ばして、次のチュートリアルに進んでください。(このチュートリアル)

Quick Start

Create React Native App is the easiest way to start building a new React Native application. It allows you to start a project without installing or configuring any tools to build native code – no Xcode or Android Studio installation required (see Caveats).

Create React App は、新規のリアクト・ネイティブ・アプリケーションを作るうえで一番簡単な方法です。native コードをビルドするために、他のツールのインストールや設定がまったく必要ありません。Xcode も Android Studio もインストールする必要がありません。

Assuming that you have Node installed, you can use npm to install thecreate-react-native-appcommand line utility:

ただし、Node がインストールされており、npm をつかってコマンドラインから create-react-app をインストールできる必要があります。

では次のコマンドでインストールしていきましょう。

$ npm install -g create-react-native-app

Then run the following commands to create a new React Native project called “AwesomeProject”:

以下のコマンドで、”Awesome Project”という名称の新規の React Native プロジェクトを作成しましょう。

$ create-react-native-app AwesomeProject
$ cd AwesomeProject
$ npm start

This will start a development server for you, and print a QR code in your terminal.

これで開発用サーバーが立ち上がり、QR コードがターミナルに表示されます。

Running your React Native application

Install theExpo client app on your iOS or Android phone and connect to the same wireless network as your computer. Using the Expo app, scan the QR code from your terminal to open your project.

クライアントアプリケーションの Expo をご自身の iOS もしくは Android にインストールして、使用しているコンピューターと同じワイヤレスネットワークに接続してください。Expo アプリを使って ターミナルに表示された QR コードをスキャンをしましょう。するとプロジェクトが端末上で展開されます。

Modifying your app

Now that you have successfully run the app, let’s modify it. Open App.js in your text editor of choice and edit some lines. The application should reload automatically once you save your changes.

さてこれでアプリケーションを走らせることに成功しましたので、次は変更をくわえてきいきましょう。App.js をテキストエディターで開いて編集していきます。変更を加えると、自動的にアプリケーションがリロードされます。

That’s it!

Congratulations! You’ve successfully run and modified your first React Native app.

おめでとうございます。最初の React Native アプリを走らせて、さらに変更を加えることに成功しましたね。

Now what?

次にどうすればいいか。

  • Create React Native App also has a user guideyou can reference if you have questions specific to the tool.

  • User guideがあるので、Create React Native Appに関して疑問があれば参照してください。

  • If you can’t get this to work, see the Troubleshooting section in the README for Create React Native App.

  • うまくこのチュートリアルが動かなかった場合には、Troubleshooting を読んでください。

If you’re curious to learn more about React Native, continue on to the Tutorial.

React Native について興味がうまれてもっと学びたいという場合には Tutorial を読み続けてください。

Running your app on a simulator or virtual device

作成したアプリケーションを、シミュレータもしくは仮想デバイス上で動かす

Create React Native App makes it really easy to run your React Native app on a physical device without setting up a development environment. If you want to run your app on the iOS Simulator or an Android Virtual Device, please refer to the instructions for building projects with native code to learn how to install Xcode and set up your Android development environment.

Create React Native App は、開発環境の設定をする必要がないので非常に簡単に、実際の物理デバイス上でアプリケーションを走らせることができます。ですが、アプリケーションを iOS シミュレータや Android の仮想デバイス上で動かしたい場合には、Xcode のインストールと Android 開発環境のセットアップに関する説明を読んでください。

Once you’ve set these up, you can launch your app on an Android Virtual Device by running npm run android, or on the iOS Simulator by running npm run ios (macOS only).

セットアップが完了しさえすれば、Android Virtual Device の場合には npm run androidと実行すればアプリケーションをその上で動かすことができます。iOS シミュレータの場合にはnpm run iosと実行してください。(ただし iOS シミュレータは macOS でしか提供されていません)

iOS シミュレータもしくは Android Virtual Device でアプリケーションを動かすための準備

Installing dependencies

You will need Node, Watchman, the React Native command line interface, and Xcode.

Node, Watchman, React Native command line interface, Xcode が必要です。

While you can use any editor of your choice to develop your app, you will need to install Xcode in order to set up the necessary tooling to build your React Native app for iOS.

開発に使うのは、どんなエディターでもかまいませんが、まず Xcode をインストールして、React Native app をビルドするのに必要なツールを用意する必要があります。

Node, Watchman

We recommend installing Node and Watchman using Homebrew. Run the following commands in a Terminal after installing Homebrew:

Node と Watchman のインストールには Homebrew をしようすることを推奨します。Homebrew をインストールした後に、以下のコマンドをターミナルで実行してください。

$ brew install node
$ brew install watchman

If you have already installed Node on your system, make sure it is version 4 or newer.

すでに Node をインストールしている場合には、そのバージョンが 4 以上であるようにしてください。

Watchman is a tool by Facebook for watching changes in the filesystem. It is highly recommended you install it for better performance.

Watchman は Facebook が開発したツールで、filesystem の変更を監視します。より良いパフォーマンスのために、このツールをインストールすることを強く推奨いたします。

The React Native CLI

Node comes with npm, which lets you install the React Native command line interface.

Node に付随している npm を使用して、React Native command line interface をインストールしましょう。

Run the following command in a Terminal:

以下のコマンドをターミナルで実行します。

$ npm install -g react-native-cli

If you get an error like Cannot find module 'npmlog', try installing npm directly: curl -0 -L https://npmjs.org/install.sh | sudo sh.

次のようなエラーが出る場合には Cannot find module 'npmlog'、npm をダイレクトにインストールしてください: curl -0 -L https://npmjs.org/install.sh | sudo sh.

Xcode

The easiest way to install Xcode is via the Mac App Store. Installing Xcode will also install the iOS Simulator and all the necessary tools to build your iOS app.

Xcode をインストールする一番簡単な方法は Mac App Store を使うことです。Xcode をインストールすると、同時に iOS Simulator と iOS app をビルドするために必要なツール一式もインストールしてくれます。

If you have already installed Xcode on your system, make sure it is version 8 or higher.

Xcode をすでにインストールしている場合には、バージョンが8以上であるようにしてください。

Command Line Tools

You will also need to install the Xcode Command Line Tools. Open Xcode, then choose “Preferences…” from the Xcode menu. Go to the Locations panel and install the tools by selecting the most recent version in the Command Line Tools dropdown.

Xcode Command Line Tool もインストールする必要があります。Xcode を開いて、”Preferences…” を Xcode のメニューから洗濯してください。Location パネルに移動し、Command Line Tools のドロップダウンから、一番最新のものを選択してインストールします。

Caveats

Because you don’t build any native code when using Create React Native App to create a project, it’s not possible to include custom native modules beyond the React Native APIs and components that are available in the Expo client app.

If you know that you’ll eventually need to include your own native code, Create React Native App is still a good way to get started. In that case you’ll just need to “eject” eventually to create your own native builds. If you do eject, the “Building Projects with Native Code” instructions will be required to continue working on your project.

Create React Native App configures your project to use the most recent React Native version that is supported by the Expo client app. The Expo client app usually gains support for a given React Native version about a week after the React Native version is released as stable. You can check this document to find out what versions are supported.

If you’re integrating React Native into an existing project, you’ll want to skip Create React Native App and go directly to setting up the native build environment. Select “Building Projects with Native Code” above for instructions on configuring a native build environment for React Native.

Learn the Basics

React Native is like React, but it uses native components instead of web components as building blocks. So to understand the basic structure of a React Native app, you need to understand some of the basic React concepts, like JSX, components, state, and props. If you already know React, you still need to learn some React-Native-specific stuff, like the native components. This tutorial is aimed at all audiences, whether you have React experience or not.
 
React Native は React と似ています。ただし、アプリケーションを構成するために、Web Component ではなく Native Component を用いる点は異なっています。ですので React Native App の基本的な概念を学ぶためには、React の基礎的な概念を理解する必要があります。例えば JSX, component, state, prop といった概念などです。React をすでに知っているのであれば、さらに進んで native component のような React Native に特有の概念を学んでいく必要があります。本チュートリアルは、React の経験がある人もない人も、全ての方向けに作成されています。
 
Let’s do this thing.
 
では進めていきましょう。
 

Hello World

 
In accordance with the ancient traditions of our people, we must first build an app that does nothing except say “Hello world”. Here it is:
 
太古からの我々の伝統に乗っ取り、「Hello, world」と言う以外に何もしないアプリケーションを構築しましょう。
 
If you are feeling curious, you can play around with sample code directly in the web simulators. You can also paste it into your App.js file to create a real app on your local machine.
 
興味があれば、サンプルコードを Web シミュレータ上で直接実行してみてください。もしくは上記のコードを App.js ファイルにペースとして、ローカルマシーン上の実際のアプリケーションの上で実行してみましょう。
 

What’s going on here?

 
何がおきているか
 
Some of the things in here might not look like JavaScript to you. Don’t panic. This is the future.
 
ここで起きていることは、JavaScript のようには見えないかもしれません。動転しないでください。これは次世代の JavaScript なんです。
 
First of all, ES2015 (also known as ES6) is a set of improvements to JavaScript that is now part of the official standard, but not yet supported by all browsers, so often it isn’t used yet in web development. React Native ships with ES2015 support, so you can use this stuff without worrying about compatibility. import, from, class, extends, and the () => syntax in the example above are all ES2015 features. If you aren’t familiar with ES2015, you can probably pick it up just by reading through sample code like this tutorial has. If you want, this page has a good overview of ES2015 features.
 
訳注:ES2015 についての解説。ES2015について慣れていない人は、this pageを参照。
 
The other unusual thing in this code example is <Text> Hello world!</Text>. This is JSX – a syntax for embedding XML within JavaScript. Many frameworks use a special templating language which lets you embed code inside markup language. In React, this is reversed. JSX lets you write your markup language inside code. It looks like HTML on the web, except instead of web things like <div> or <span>, you use React components. In this case, <Text> is a built-in component that just displays some text.
 
訳注:<Text> は見慣れない構文であるが、これはJSX の記法。React Compont の呼び出し。詳しくは React そのもののマニュアルを参照。
 

Components

 
So this code is defining HelloWorldApp, a new Component. When you’re building a React Native app, you’ll be making new components a lot. Anything you see on the screen is some sort of component. A component can be pretty simple – the only thing that’s required is a render function which returns some JSX to render.
 
ということで上記のコードは、HelloWorldApp という新しいコンポーネントを定義しています。React Native app を構築していくにあたって、新しいコンポーネントをたくさん作っていくことになります。スクリーンに写っているものはどれでも全て、このようなコンポーネントでできています。コンポーネントは非常にシンプルです。必要なのは、レンダリングされる JSX を return する render function を持っていることだけです。
 

This app doesn’t do very much

 
このアプリはほとんど何もしていませんね。
 
Good point. To make components do more interesting things, you need to learn about Props.
 
おっしゃる通りです。もっと面白いことをするために、次に Props を学びましょう。
 

Props

 
Most components can be customized when they are created, with different parameters. These creation parameters are called props.
 
ほとんどのコンポーネントは、作成される際に、異なるパラメーターを元に、カスタマイズすることができます。この際に用いるパラメーターが、props です。
 
For example, one basic React Native component is the Image. When you create an image, you can use a prop named source to control what image it shows.
 
例えば、React Native コンポーネントの基礎的なものの一つして Image がありますが、この Image を作成する際に、source という名前の prop を用いることで Image コンポーネントが何を表示するかを制御することができます。
 
Notice that {pic} is surrounded by braces, to embed the variable pic into JSX. You can put any JavaScript expression inside braces in JSX.
 
{pic} というふうに、{} で囲まれている点に着目してください。これによって pic と言う変数を JSX の中に埋め込んでいます。JSX 内に {} によって、どんな JavaScript expression も埋め込むことができます。
 
Your own components can also use props. This lets you make a single component that is used in many different places in your app, with slightly different properties in each place. Just refer to this.props in your render function. Here’s an example:
 
自分作成したコンポーネントにも props を用いることができます。これによって、同じコンポーネントを様々な場所で、少しだけ異なる内容を持たせて使用することが可能になります。Render function の中で、this.props を参照するだけです。
 
Using name as a prop lets us customize the Greeting component, so we can reuse that component for each of our greetings. This example also uses the Greeting component in JSX, just like the built-in components. The power to do this is what makes React so cool – if you find yourself wishing that you had a different set of UI primitives to work with, you just invent new ones.
 
name という prop を用いることで、Greeting コンポーネントをカスタマイズすることができるので、同じコンポーネントをそれぞれ異なる挨拶に対して使いまわすことができます。また、この例では Greeting コンポーネントを JSX の中で用いていますが、あたかも built-in コンポーネントかのように用いています。こうすることには大きな利点があり、それによって React をとてもクールなものにしています。つまり、UI primitive(訳注:おそらく Native Cmponent のままの素朴な UI のこと) とは少し違ったものを使いたいと思った場合には、自分でそれを作ってしまえばいいのです。
 
The other new thing going on here is the View component. A View is useful as a container for other components, to help control style and layout.
 
ここではもう一つ新しいものが使われています。 View component です。View は、そのほかのコンポーネントのコンテイナーとして便利なもので、スタイルやレイアウトをコントロールする際に便利です。
 
With props and the basic Text, Image, and View components, you can build a wide variety of static screens. To learn how to make your app change over time, you need to learn about State.
 
props と 基礎的な TextImageView コンポンーネントによって、広範囲にわたる静的な画面を作り出すことができます。時間によって変化するアプリケーションを作りたい場合には、State を学ぶ必要があります。
 

State

There are two types of data that control a component: props and state. props are set by the parent and they are fixed throughout the lifetime of a component. For data that is going to change, we have to use state.
 
コンピポーネントをコントロールするために用いることができるデータには、二種類あります。一つは prop で もう一つは state です。props は親要素から渡され、コンポーネントのライフタイムを通して固定されます。変化するデータに関しては、state を使う方が良いでしょう。
 
In general, you should initialize state in the constructor, and then call setState when you want to change it.
 
一般的に言って、コンストラクタにおいて state を初期化し、それを変える場合には setState を用います。
 
For example, let’s say we want to make text that blinks all the time. The text itself gets set once when the blinking component gets created, so the text itself is a prop. The “whether the text is currently on or off” changes over time, so that should be kept in state.
 
例えば、テキストを時間経過にあわせて点滅させたいとします。テキスト自体は Blink コンポーネントが生成された際にコンポーネント自体に与えられ保持します。その際には prop 経由でテキストの内容を与えられます。
 
In a real application, you probably won’t be setting state with a timer. You might set state when you have new data arrive from the server, or from user input. You can also use a state container like Redux to control your data flow. In that case you would use Redux to modify your state rather than calling setState directly.
 
実際のアプリケーションの場合には、state をタイマーを使ってセットするようなことはないでしょう。どちらかといえば、サーバーから新しいデータを取得した際や、ユーザーがインプットした際に、状態を変更するはずです。また Redux のような state container を用いて、data flow をコントロールすることもできます。その場合には Redux を使って状態を変更することになるので、setState をそのまま呼び出すことはありません。
 
When setState is called, BlinkApp will re-render its Component. By calling setState within the Timer, the component will re-render every time the Timer ticks.
 
setState が呼び出されると、BlinkApp は自分自身のコンポーネントを re-render します。Timer の中で setState を呼び出すことで、コンポーネントは Timer が駆動するたびに、コンポーネントを re-render します。
 
State works the same way as it does in React, so for more details on handling state, you can look at the React.Component API. At this point, you might be annoyed that most of our examples so far use boring default black text. To make things more beautiful, you will have to learn about Style.
 
React Native における State は React における State と全く同じように動作しますので、state の扱いをより知りたい場合には React Component API を参照ください。さて、この時点では我々の例示が今のところは退屈な黒いだけのテキストであることに、苛立ちを感じていることでしょう。より装飾的にするために、次は Style を学んでいきます。
 

Style

With React Native, you don’t use a special language or syntax for defining styles. You just style your application using JavaScript. All of the core components accept a prop named style. The style names and values usually match how CSS works on the web, except names are written using camel casing, e.g backgroundColor rather than background-color.
 
React Native 使う場合、スタイルを定義するための、特別な言語やシンタックスは必要ありません。単に JavaScript を使ってアプリケーションをスタイリングしていきます。全てのコアとなるコンポーネントは、style という名前の prop を受け付けます。スタイルの名前とあたいはほとんど web で一般的に使われる CSS と同じですが、例外は名前がキャメルケースを使って書かれているものです。例えば backgroundColor とすべきで、background-color としてはいけません。
 
The style prop can be a plain old JavaScript object. That’s the simplest and what we usually use for example code. You can also pass an array of styles – the last style in the array has precedence, so you can use this to inherit styles.
 
style prop は普通の伝統的な JavaScript のオブジェクトを渡します。これが一番シンプルな形式で、サンプルコードでは一般的にこのタイプが使われます。また style の配列を渡すこともできます。配列の最後のスタイルが適応されますので、これをつかってスタイルを継承させることができます。(訳注:おそらく、配列の前から後ろへと上書きされていくということがいわれていると思われる。)
 
As a component grows in complexity, it is often cleaner to use StyleSheet.create to define several styles in one place. Here’s an example:
 
コンポーネントが複雑になるにつれて、StyleSheet.create を用いて複数のスタイルを一箇所にまとめた方が、より綺麗に整頓できるはずです。次のように。
 
One common pattern is to make your component accept a style prop which in turn is used to style subcomponents. You can use this to make styles “cascade” the way they do in CSS.
 
よくある手法として、コンポーネントには一つだけの style prop を受け取らせて、それを用いてサブコンポーネントをもスタイリングさせる手法です。これを用いて style を “cascade” することができます。これは CSS でも行われる手法ですね。(訳注:よくわからない。実例が欲しいところ。)
 
There are a lot more ways to customize text style. Check out the Text component reference for a complete list.
 
text のスタイリングをする方法はたくさんあります。Text component のリファレンスを参照してください。
 
Now you can make your text beautiful. The next step in becoming a style master is to learn how to control component size.
 
さあ Text を美しく装飾することができました。次なる style マスターへの一歩は、コンポーネントのサイズをコントロールすることです。
 

Height and Width

A component’s height and width determine its size on the screen.
 
コンポーネントの高さと幅の定義によって、スクリーン上に表示されるサイズを規定します。
 

Fixed Dimensions

 
固定サイズの場合
 
The simplest way to set the dimensions of a component is by adding a fixed width and height to style. All dimensions in React Native are unitless, and represent density-independent pixels.
 
コンポーネントの縦横幅を決める一番簡単な方法は、style で幅と高さを与えることです。React Native に置ける全ての縦横幅は、untiless で、density-independent pixel を表しています。(訳注:1px がどのような規格基準での 1px なのかを表していると思われる)
 
Setting dimensions this way is common for components that should always render at exactly the same size, regardless of screen dimensions.
 
このような方法で縦横幅を設定する方法は、いつでも同じサイズでレンダリングされるべきコンポーネントのために一般的に使われます。スクリーンのサイズがどうであれ一定幅でレンダリングする場合です。
 

Flex Dimensions

 
状況に合わせて伸縮する縦横幅
 
Use flex in a component’s style to have the component expand and shrink dynamically based on available space. Normally you will use flex: 1, which tells a component to fill all available space, shared evenly amongst each other component with the same parent. The larger the flex given, the higher the ratio of space a component will take compared to its siblings.
 
コンポーネントの Style の中で flex を用いることで、使用可能なスペースに合わせて伸び縮みさせることができます。flex: 1 を用いると、コンポーネントに対して使えるスペース全部を埋めるように支持することになります。ただしその際に同じ親コンポーネントを持つ隣接するコンポーネントとその領域をわけあうことになります。flex の値が大きくなるほど、兄弟要素の間で、占める割合が増すことになります。
 
_A component can only expand to fill available space if its parent has dimensions greater than 0. If a parent does not have either a fixed width and height or flex, the parent will have dimensions of 0 and the flex children will not be visible.
_
 
コンポーネントは使用可能なスペース全てを埋めるわけですが、それは親要素の縦横幅が 0 以上の場合に限られます。もし親要素に高さや幅を固定もしくは flex で指定されてない場合、親要素の縦横幅が 0 になってしまうので、その子要素に flex が指定されていたとしても、見えなくなってしまいます。
 
After you can control a component’s size, the next step is to learn how to lay it out on the screen.
 
コンポーネントのサイズをコントロールできるようになったので、次はスクリーン上にどのようにレイアウトするのかを学習します。

webstorm standard js成形

https://standardjs.com/webstorm.html

これの local install でeslint を入れるパターンで、エラーが出たら fix this file で直すのがいいと思われる。

さらに組み合わせで js の standard スタイルを webstorm のフォーマッティングに適応しておくと formatting で大体なおる。ただし大体しかなおらない。(例えば改行は消さないし、コンポーネントの後ろにはスペースが入ってしまう。これはeslintのほうでなおす。)

Redux 公式ドキュメントのリポジトリ→ GitHub fork → GitBook の連携

以前から勝手に OSS ドキュメントの翻訳をしてはこのブログに公開していましたが、読みにくいというクレームをよく頂いておりました。しかし、そうは言われても、公式ページと同じ公開方式 (例えば GitHub Pages や GitBook 形式がよく使われています) で翻訳した結果を公開するのは、少し自分には難しい…と思っておりました。

が、ついに綺麗なフォーマットで公開できそうです。

Redux の公式ドキュメントは GitBook 形式なのですが、GitBook にするためのソースは全て GitHub で公開されています。これを以下の手順で処理して、翻訳していきます。

  1. まずは自分の GitHub アカウントを持つ。
  2. Redux ドキュメントの GitHub リポジトリから自分の GitHub へ Fork する。
  3. GitBook のアカウントと、自分の GitHub アカウントを連携させる。
  4. 自分の GitHub アカウント内の Fork した Redux ドキュメントのリポジトリを、GitBook 上で読み込む。
  5. GitBook のブラウザ・エディタで翻訳する。
  6. GitBook で Publish すると、GitBook 上のリポジトリにも、連携している自分の GitHub リポジトリにも自動的に反映される。

こうすると次のような利点があります。

  1. GitBook と GitHub が sync するので、どちらか一方を編集した際に、もう一方も変更される。
  2. GitBook のウェブ上のエディターを用いることで、GitBook で公開されるフォーマットとほぼ同じ形のまま、編集・翻訳できる。
  3. GitBook で Publish すると、その結果が GitHub にコミットされるので、GitHub で OSS に貢献している雰囲気が非常に出る。(活動ログに濃い緑色のマップが作成できる)

Continue reading “Redux 公式ドキュメントのリポジトリ→ GitHub fork → GitBook の連携”

React v16.0 メジャーバージョンアップ

例によって勝手に翻訳

https://reactjs.org/blog/2017/09/26/react-v16.0.html

個人的な react 16 関連情報リスト

React v16.0

We’re excited to announce the release of React v16.0! Among the changes are some long-standing feature requests, including fragmentserror boundariesportals, support for custom DOM attributes, improved server-side rendering, and reduced file size.

React v16.oのリリースをお知らせできることに、胸が高鳴っています。今回の変更の中には、皆さんから長く要望いただいていた機能もあります。fragmentserror boundariesportals, custom DOM attributes のサポート, 改善された server-side rendering, そして reduced file size などです。

New render return types: fragments and strings

render メソッド内における return の新しい形式:fragment と string

You can now return an array of elements from a component’s render method. Like with other arrays, you’ll need to add a key to each element to avoid the key warning:

コンポーネントの render メソッド内で、要素の配列を return することが出来るようになりました。他の配列と同様に、各要素に key を与える必要があります。これにより key warning を避けることができます。

// list item を余計な要素で囲む必要はありません。

// key を与えることを忘れずに。

render() {
  // No need to wrap list items in an extra element!
  return [
    // Don't forget the keys :)
    <li key="A">First item</li>,
    <li key="B">Second item</li>,
    <li key="C">Third item</li>,
  ];
}

In the future, we’ll likely add a special fragment syntax to JSX that doesn’t require keys.

将来的には、JSXのための特別な fragment シンタックスを提供する予定です。このシンタックスにおいては、key は必要なくなります。

We’ve added support for returning strings, too:

また文字列の return にも対応しました。

//「 見てよお母さん。span で囲まなくてもいいんだ。

render() {
  return 'Look ma, no spans!';
}

See the full list of supported return types.

Better error handling

エラー・ハンドリングの改善

Previously, runtime errors during rendering could put React in a broken state, producing cryptic error messages and requiring a page refresh to recover. To address this problem, React 16 uses a more resilient error-handling strategy. By default, if an error is thrown inside a component’s render or lifecycle methods, the whole component tree is unmounted from the root. This prevents the display of corrupted data. However, it’s probably not the ideal user experience.

以前は、レンダリング時にランタイム・エラーが生じた場合、React は壊れた状態になってしまい、意味不明なエラー・メッセージを表示していました。そしてその状態を直すためにはページを再更新する必要がありました。 このような問題に対処するため、React 16 はより柔軟性のあるエラーハンドリング戦略を用いることにしました。初期設定では、エラーがコンポーネントの render メソッドやライフサイクル・メソッドの中で生じた場合、コンポーネント・ツリー全体が、ルートコンポーネントからアンマウントされるようになっています。これによって、壊れたデータが表示されることを防いでいます。しかし、おそらくこれは、理想的なユーザー体験とは言い難いものです。

Instead of unmounting the whole app every time there’s an error, you can use error boundaries. Error boundaries are special components that capture errors inside their subtree and display a fallback UI in its place. Think of error boundaries like try-catch statements, but for React components.

エラーが生じる度にアプリケーション全体をアンマウントするのではなく、代わりに「Error Boundaries」を用いることができます。「Error boundaries」は、特別なコンポーネントで、自身の下層にあるツリーで生じたエラーを捉えて、フォールバック UI を代わりに表示します。「Error boundaries」は、トライ/キャッチ文と同じようなものだと考えてもいいでしょう。ただし React コンポーネントのためのトライ/キャッチ文です。

For more details, check out our previous post on error handling in React 16.

詳細は previous post on error handling in React 16 を確認ください。

Portals

Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.

「portal」機能は、子要素を、親コンポーネントのDOMヒエラルキーの外側に存在するDOM node に対して、レンダリングする機能です。

render() {
  // React does *not* create a new div. It renders the children into `domNode`.
  // `domNode` is any valid DOM node, regardless of its location in the DOM.
  return ReactDOM.createPortal(
    this.props.children,
    domNode,
  );
}

See a full example in the documentation for portals.

(訳注: react は通常、自分の子要素の位置にコンポーネントをレンダリングするが、portal を用いると、その縛りから放たれて、どの DOM に対してもコンポーネントをレンダリングをできるようだ。具体的なユースケースとして、overflow: hidden されている親要素の中のコンポーネントから、モーダルウィンドウを生成したい場合があげられている。通常であれば、overflow: hidden されている要素の子要素として DOM がレンダリングされる以上、親要素の外にはみ出るような視覚表現を作り出すことができない。このような条件において、親要素の外側に DOM をレンダリングする必要が発生し、その場合に portal 機能が有用となる。)

Better server-side rendering

サーバーサイドレンダリングの改善

React 16 includes a completely rewritten server renderer. It’s really fast. It supports streaming, so you can start sending bytes to the client faster. And thanks to a new packaging strategy that compiles away process.env checks (Believe it or not, reading process.env in Node is really slow!), you no longer need to bundle React to get good server-rendering performance.

React 16 は、完全に新たに書き直された server render を用いています。これによって非常に早くなりました。この新しい server render は、ストリーミングをサポートしており、非常に早くクライアントへの情報送信を開始することができるようになりました。また  new packaging strategy のお陰で(これはprocess.env のチェックをコンパイルから取り除いています。信じられないかもしれませんが、Node の process.env は本当に遅いのです!)、サーバーレンダリングのパフォーマンスをよくするためにReact をバンドルする、ということが必要なくなりました。

Core team member Sasha Aickin wrote a great article describing React 16’s SSR improvements. According to Sasha’s synthetic benchmarks, server rendering in React 16 is roughly three times faster than React 15. “When comparing against React 15 with process.env compiled out, there’s about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!” (As Sasha points out, please be aware that these numbers are based on synthetic benchmarks and may not reflect real-world performance.)

React 開発のコアメンバーである「Sasha Aickin」がRact 16 の SSR が大きく進歩したということについて記事を書いています。「great article describing React 16’s SSR improvements」 Sahsa のシンセティック・ベンチマークによればReact 16 のサーバーレンダリングは、ざっくりって React 15 の3倍は早いことがわかりました。「process.env をコンパイルした React15 と比較すると、node 4 では2.4倍の改善がされ、node 6 では3倍の、そして最新のnode 8.4 では3.8倍の改善がされました。そしてコンパイルなしの react 15 と比較するとすれば、最新バージョンの Node では、なんと一桁違う改善がされています!」(Sashaが指摘していることですが、この数字はシンセティック・ベンチマークによるもので、実際のパフオーマンスを、必ずしも反映するものではない点に注意してください。)

In addition, React 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible. No more checksums! In general, we don’t recommend that you render different content on the client versus the server, but it can be useful in some cases (e.g. timestamps).

加えて、React 16 は hydrating server-rendered HTML を改善しています。(ただし一旦クライアントにリーチした場合のみですが) 最早、サーバーからの結果と完全にマッチさせるために最初のレンダリングをする、という必要がなくなりました。その代わりに、既に存在するDOMを最大限、再活用するようになりました。もうチェックサムは必要ありません!一般的に言って、クライアント側とサーバー側で異なるコンテンツをレンダリングすることは、おすすめしません。とはいえ有効なケースもあります。(例えばtimestampなど)

See the documentation for ReactDOMServer for more details.

Support for custom DOM attributes

カスタム DOM 属性のサポート

Instead of ignoring unrecognized HTML and SVG attributes, React will now pass them through to the DOM. This has the added benefit of allowing us to get rid of most of React’s attribute whitelist, resulting in reduced file sizes.

HTML と SVG の React が認識できない属性に関して、今まで React は無視をしてきましたが、React 16 ではそのまま DOM に渡すようになりました。これによって以前のReactのホワイト・リストを使わなくて良くなるので、結果としてファイルサイズが小さくなります。

Reduced file size

小さくなったファイルサイズ

Despite all these additions, React 16 is actually smaller compared to 15.6.1!

様々な機能追加にもかかわらず、React 16 は 15.6.1 よりもファイルサイズが小さくなりました!

  • react is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped).
  • react-dom is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped).
  • react + react-dom is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped).

That amounts to a combined 32% size decrease compared to the previous version (30% post-gzip).

The size difference is partly attributable to a change in packaging. React now uses Rollup to create flat bundles for each of its different target formats, resulting in both size and runtime performance wins. The flat bundle format also means that React’s impact on bundle size is roughly consistent regardless of how you ship your app, whether it’s with Webpack, Browserify, the pre-built UMD bundles, or any other system.

サイスが小さくなった理由の一部は、packaging 方法の変更にあります。React は Rollup を用い、異なった対象のフォーマットへのフラットバンドルを作っています。結果としてサイズの点でもランタイム・パフォーマンスの点でも向上しました。フラットバンドルフォーマットであるということは同時に次のことも意味します。つまり、Webpack, Browserify, the pre-built UMD bundles, や他のどのシステムを用いてアプリケーションを最終的にバンドルするとしても、Reactのバンドルサイズは小さいままです。

MIT licensed

In case you missed it, React 16 is available under the MIT license. We’ve also published React 15.6.2 under MIT, for those who are unable to upgrade immediately.

React 16 は MIT ライセンスで運用されます。15.6.2 も同じく MIT ライセンスでした。

New core architecture

新しいコア・アーキテクチャ

React 16 is the first version of React built on top of a new core architecture, codenamed “Fiber.” You can read all about this project over on Facebook’s engineering blog. (Spoiler: we rewrote React!)

React 16 は新しいコアアーキテクチャである”Fiber”のもと構築された、最初のReact です。このプロジェクトの全貌については Facebook’s engineering blog の記事で知ることができます。

Fiber is responsible for most of the new features in React 16, like error boundaries and fragments. Over the next few releases, you can expect more new features as we begin to unlock the full potential of React.

“Fiber” こそが、React 16 の新機能の多くの立役者です。error boundaries や fragment といった新機能は Fiber によって成り立っています。次に続くいくつかのリリースでも、さらに多くの新機能を追加する予定です。React のポテンシャルを最大限引き出していきます。

Perhaps the most exciting area we’re working on is async rendering—a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.

おそらく一番エキサイティングな部分は「async rendering」でしょう。

This demo provides an early peek at the types of problems async rendering can solve:

 Follow
Andrew Clark @acdlite

Ever wonder what “async rendering” means? Here’s a demo of how to coordinate an async React tree with non-React work https://gist.github.com/acdlite/f31becd03e2f5feb9b4b22267a58bc1f 

Twitter Ads info and privacy

Tip: Pay attention to the spinning black square.

We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we’re not enabling any async features yet, but we’re excited to start rolling them out in the coming months. Stay tuned!

Installation

React v16.0.0 is available on the npm registry.

React v16.0.0 は npm レジストリ上で手に入れることができます。

To install React 16 with Yarn, run:

Yarn を用いて React 16 をインストールするには、次のコマンドを実行してください。

yarn add react@^16.0.0 react-dom@^16.0.0

To install React 16 with npm, run:

npm を用いて React 16 をインストールするには、次のコマンドを実行してください。 

npm install --save react@^16.0.0 react-dom@^16.0.0

We also provide UMD builds of React via a CDN:

また、React の UMD ビルドを CDN を通じて提供しています。

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Refer to the documentation for detailed installation instructions.

Upgrading

Although React 16 includes significant internal changes, in terms of upgrading, you can think of this like any other major React release. We’ve been serving React 16 to Facebook and Messenger.com users since earlier this year, and we released several beta and release candidate versions to flush out additional issues. With minor exceptions, if your app runs in 15.6 without any warnings, it should work in 16.

React 16 は莫大な内部変更が加えられましたが、アップグレードという観点からいえば、他の React メジャーバージョンアップのリリースと変わりません。我々は既に今年の初めには React 16 を Facebook や Messenger.com のサービスに使用しており、幾つかのベータ版と候補バージョンを出して、機能を追加してきました。いくつかの細かな例外を除けば、あなたのアプリケーションが 15.6 上で warning なしに動いているのであれば、基本的に 16 上でも動作します。

New deprecations

Hydrating a server-rendered container now has an explicit API. If you’re reviving server-rendered HTML, use ReactDOM.hydrate instead of ReactDOM.render. Keep using ReactDOM.render if you’re just doing client-side rendering.

「Hydrating a server-rendered container」に関しては、新たに明示的な API を持つことになりました。「reviving server-rendered HTML」しているのであれば、ReactDOM.render ではなく ReactDOM.hydrate を使用してください。単にクライアントサイドレンダリングをしている場合には、いつもどおりReactDOM.render を使用してください。

React Addons

As previously announced, we’ve discontinued support for React Addons. We expect the latest version of each addon (except react-addons-perf; see below) to work for the foreseeable future, but we won’t publish additional updates.

既に発表した通り、React Addons のサポートを打ち切りました。それぞれのaddon の最終バージョンは、しばらく問題なく動くはずですが、しかし新たな更新をする予定はありません。

Refer to the previous announcement for suggestions on how to migrate.

react-addons-perf no longer works at all in React 16. It’s likely that we’ll release a new version of this tool in the future. In the meantime, you can use your browser’s performance tools to profile React components.

react-addons-perfは React 16 では動きません。おそらく新しいこういったツールを将来発表するはずです。しばらくのあいだは、ブラウザのパフォーマンスツールを使ってReact コンポーネントの捜査を行ってください。 (use your browser’s performance tools to profile React components.)

Breaking changes

破壊的変更

React 16 includes a number of small breaking changes. These only affect uncommon use cases and we don’t expect them to break most apps.

React 16 はかなりの数の破壊的変更が加えられました。これらが影響をあたえるのはかなり特殊なケースで運用されているアプリケーションに限られており、ほとんどのアプリケーションにおいて、動かなくなることはないと予想しています。

  • React 15 had limited, undocumented support for error boundaries using unstable_handleError. This method has been renamed to componentDidCatch. You can use a codemod to automatically migrate to the new API.
  • ReactDOM.render and ReactDOM.unstable_renderIntoContainer now return null if called from inside a lifecycle method. To work around this, you can use portals or refs.
  • setState:
    • Calling setState with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.
    • Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.
    • setState callbacks (second argument) now fire immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.
  • When replacing <A /> with <B />B.componentWillMount now always happens beforeA.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.
  • Previously, changing the ref to a component would always detach the ref before that component’s render is called. Now, we change the ref later, when applying the changes to the DOM.
  • It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. See this example.
  • componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)
  • Shallow renderer no longer calls componentDidUpdate because DOM refs are not available. This also makes it consistent with componentDidMount (which does not get called in previous versions either).
  • Shallow renderer does not implement unstable_batchedUpdates anymore.
  • ReactDOM.unstable_batchedUpdates now only takes one extra argument after the callback.

Packaging

  • There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in a new issue, and we’ll try to figure out a migration strategy for you.
  • There is no react-with-addons.js build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.
  • The deprecations introduced in 15.x have been removed from the core package. React.createClass is now available as create-react-classReact.PropTypes as prop-typesReact.DOM as react-dom-factoriesreact-addons-test-utils as react-dom/test-utils, and shallow renderer as react-test-renderer/shallow. See 15.5.0 and 15.6.0 blog posts for instructions on migrating code and automated codemods.
  • The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
    • react/dist/react.js → react/umd/react.development.js
    • react/dist/react.min.js → react/umd/react.production.min.js
    • react-dom/dist/react-dom.js → react-dom/umd/react-dom.development.js
    • react-dom/dist/react-dom.min.js → react-dom/umd/react-dom.production.min.js

JavaScript Environment Requirements

React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.

React 16 は Map や Set に依存しています。そのためこれらをサポートしてない古いブラウザにおいては(例えばIE11未満)、グローバルな polyfill をバンドルアプリケーションに含めることを検討してください。例えば core-js や babel-polyfill などを用いてください。

A polyfilled environment for React 16 using core-js to support older browsers might look like:

次のソースは、古いブラウザでも react 16 が動くようにするために、core-js を用いて React 16 のための polyfill が適用された環境の例です。

import 'core-js/es6/map';
import 'core-js/es6/set';

import React from 'react';
import ReactDOM from 'react-dom';

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

React also depends on requestAnimationFrame (even in test environments). A simple shim for test environments would be:

React は  requestAnimationFrame にも依存しています。(テスト環境においても依存してます) テスト環境用のシンプルな shim は以下のようになります。

global.requestAnimationFrame = function(callback) {
  setTimeout(callback, 0);
};

Acknowledgments

As always, this release would not have been possible without our open source contributors. Thanks to everyone who filed bugs, opened PRs, responded to issues, wrote documentation, and more!

Special thanks to our core contributors, especially for their heroic efforts over the past few weeks during the prerelease cycle: Brandon Dail, Jason Quense, Nathan Hunzaker, and Sasha Aickin.

Edit this page

React / Functional Component の書き方のバリエーション

(インデントが崩れてしまうのは自分が使っているwordpressプラグインの仕様のようです…困った)

https://hackernoon.com/react-stateless-functional-components-nine-wins-you-might-have-overlooked-997b0d933dbc

//1.基本形
//もしこの例の用に、JSXを返すだけであれば3.省略形を使ってもいい
import React from 'react';

const App = ()=> {
  return (
    

<div>This is App component</div>


  );
};

export default App;

//2.propsを受け取る場合 また関数や変数を持たせる場合
//classで書いた場合と異なり、thisの扱いをしなくていいので、楽
//stateをもたせる必要がなければこれでいい
import React from "react";

const App = ({ name }) => {
  const mrName = "Mr. " + name;
  const alertName = name => {
    alert(name);
  };
  return (
    

<div>
      

<div>
        this is Component {mrName}
      </div>


      <button onClick={() => {
          alertName(name);
        }}
      />
    </div>


  );
};

export default App;
//3.省略形
//単にjsxを返すだけであれば、これが一番シンプルな記述
import React from 'react';

const App = ()=> (
  

<div>This is App component</div>


);

export default App;

CSS Transition と Keyframe Animation 違いと優位性

いつもはVelocity.jsをつかってアニメーションを書いているのですが、マウスホバー時のアニメーションをリッチにしたり、ReactでDOMを再レンダリングした時に目を引くためのアニメーションをさせる、そんなときにはCSSベースでアニメーションを書いたほうが、メンテナンスが簡単そう等々、利点があるなと最近感じました。

そこでTransitionとKeyframeを使ったアニメーションに関して、いくつか役にたった記事を集めて、英語のものは勝手に翻訳します。

ざっくりデモ https://codepen.io/nakanishi/pen/gxQzoZ

CSS Transitions VS Keyframe Animations

There are currently two ways to animate things with CSS:

現在、アニメーションをCSSで実装する方法は2つあります。TransitionとKeyframe Animationです。
  • Transitions
  • Keyframe Animations

Each technique has similarities and differences. Here’s how they work.

それぞれの技術は同じ点もありますし、異なる点もあります。これらの技術がどのように機能しているのか、みていきましょう。

Transitions

Transitions work by morphing a property from one value to another when the transition is triggered.

Transitionは、Propertyをある値から別の値へと変化させることで、動作します。これはトランジションがトリガーされた際におきます。

Here is a simple example (hover your mouse over the box to trigger the transition):

次の簡単な例をごらんください。

JS Bin

There are several ways to trigger a transition. The most common way is with the :hover pseudo-class (which you saw in the example above), but others include:

トランジションをトリガーする方法はいくつかあります。一番一般的な方法は、:hover疑似クラスを用いる方法ですが、他にも方法があります。

  • :active
  • :focus
  • :checked
  • :disabled
  • page load
  • media queries
  • device orientation
  • class changes (Triggered via javascript)

(By the way, there’s a great article by Louis Lazaris demonstrating some examples of these techniques) これらのテクニックを使ったサンプルが上記の記事で紹介されています。

In all cases, a user performs some action, which sets our transition in motion. You can adjust many properties of the transition, like the delay or timing, but all transitions must have a beginning and an end.

どのケースにおいても、ユーザーがなんらかのアクションを起こし、それがトランジションにモーションを与えます。トランジションの多くのpropertyを調整することが出来ます。例えば、delayやタイミングを調整することができます。しかし、Transitonの場合には、必ず開始と終了が存在します。

Keyframe Animations

Keyframe animations are similar to transitions, in that they can be used to morph properties from one value to another, but they differ in how they are defined. You define them by identifying the keyframes that make up your animation and giving that set of keyframes a name. Then, you can invoke those keyframes anywhere you want, using CSS selectors. Let’s look at an example:

Keyframe animation は次の点ではTransitionと同じです。つまり、propertyをある値から別の値へと変化させるという点においては同じです。しかし、定義の仕方が異なります。Animationを構成するKeyframeを定義し、そのKeyframe全体に名前を与えます。その後、そのkeyframeを必要な箇所で呼び出します。その際にはCSSセレクタを用います。例を見てみましょう。

JS Bin

As you can see, we’ve defined our “pulse” keyframes, and applied it to several elements.

上記の例では、pulseという名前のkeyframeを定義し、それをいくつかの要素に対して適応しています。

Which is Better?

Both have their strengths and weaknesses. Here are a few of the main benefits I’ve found for each option:

どちらの機能にも強みと弱点があります。それぞれの選択に対する主要な利点を紹介します。

Benefits of Transition:

  • Slightly better browser support (compare transitions to animations)
  • 多少ブラウザーサポートの点で優れている(訳注:ただし2017年現在ではどちらもほとんどサポートされているので、この点はあまり考慮する必要がないかも。)
  • Familiar syntax
  • 親しみやすいシンタックス
  • Simplicity
  • 明快さ
  • Easy to manipulate in Firebug/Devtools
  • FirebugやDevtoolで扱いやすい

Benefits of Keyframes:

  • More granular timing control
  • タイミングをより詳細にコントロールすることができる
  • Easy to mix and match properties (one keyframe definition can animate color and opacity, and size, etc.)
  • 複数のプロパティを組み合わせたり、そのタイミングを合わせるのが簡単。(一つのキーフレームに、色の変更や、透明度の変更や、サイズの変更、というように複数のアニメーションを指定できる。)
  • More animation options (infinite, alternate, etc.)
  • infiniteやalternateなど、より多くのアニメーションに関するオプションがある
  • Keeps code DRY
  • コードをDRYにすることができる。

Personally, I feel like animations with keyframes are more powerful, but it really comes down to your specific application (for example, I chose to use transitions in AnchorJS and keyframe animations for my Flying Toasters).

個人的にはkeyframeを使ったアニメーションのほうが強力かなと思いますが、しかし、それぞれの状況にあわせて選択することになるでしょう。例えばAnchorJSにおいてはtranstionを使いますし、私のフライングトースターのアニメーションにはkeyframeを選択しました。

Finally, one property that is often confused with these animation techniques is transform. While transform is new and can do some neat things (like rotate, scale, translate, etc), it doesn’t animate anything. It’s a typical css property like font color or opacity.

最後に、これらのアニメーションに関する技術と、混同されているpropertyがあります。それはtransformです。transformは、新しく素晴らしい効果をもたらしてくれるものですが(rotateやscaleやtranslateなど)、アニメーションをさせるものではありません。これはCSSのプロパティであって、font-colorやopacityといったものと同じです。

CSS3 Transitions Without Using :hover

Up to this point, the most common use for CSS3 Transitions has been in conjunction with the well-known CSS :hover pseudo-class.

今までのところ、CSS3 Transitionの一番よくある使い方は、これまたよく知られた :hover 擬似クラスと組み合わせて用いる方法でした。

Here’s a typical transition that changes link color on mouseover using pure CSS:

次の例は、transitionを使った典型的なもので、リンクカラーを、マウスホバー時に変更するものです。これは全て純粋なCSSによっておこなわれています。

a, a:link, a:visited {
  color: lightblue;
  -webkit-transition: color .4s linear;
  -moz-transition: color .4s linear;
  -o-transition: color .4s linear;
  -ms-transition: color .4s linear;
  transition: color .4s linear;
}

a:hover {
  color: white;
}

This will animate the color property when you hover over a link on the page. Pretty simple, and you’ve probably seen or used something similar. But transitions are not just limited to use with :hover.

このコードはcolorプロパティを、aリンクがホバーされた際に変化させます。とてもシンプルなものであり、また多分過去にあなたも見たことがあるか、実際に書いたことがあるのではないかと思います。しかし、トランジションを使えるのは:hoverだけではないのです。

You can animate CSS properties via transitions using some other CSS techniques, a number of which I’ve outlined below. I’ve also included a demo for each example.

CSSプロパティをtransitionを用いてアニメーションさせるテクニックは色々あり、その概要を書き出しました。それぞれの項目には、デモも付けました。

Transitions Using :active

The :active pseudo-class matches any element that’s in the process of being activated. The primary way that an element is “activated” is by means of a mouse click, or mouse down.

:active擬似クラスは、全てのactiveな状態にある要素とマッチします。主な、要素をactiveにする方法は、クリックする、もしくはマウスを押し込んだ状態にすることです。

Here’s some CSS and an accompanying demo that demonstrates using :active along with CSS3 transitions to mimic a mousedown event:

次のCSSは、:activeを使ったデモです。CSS3 Transitionを使って、mousedownイベントを検知した時に発動するようになっています。

.box {
  width: 300px;
  height: 300px;
  background: #222;
  -webkit-transition: width 2s ease, height 2s ease;
  -moz-transition: width 2s ease, height 2s ease;
  -o-transition: width 2s ease, height 2s ease;
  -ms-transition: width 2s ease, height 2s ease;
  transition: width 2s ease, height 2s ease;
}

.box:active {
  width: 500px;
  height: 500px;
}

With this code, the box’s width and height properties are animated to become larger as you hold the mouse down on the element. Once you release, the box animates back to its original dimensions.

このコードは、四角の横幅と高さのpropertyがアニメーションされており、要素の上でマウスダウンしている間、それが大きくなります。マウスを離すと、元のサイズに戻ります。

Here’s a demo:

Transitions Using :focus

You can use the :focus pseudo-class to do something similar. This time we’ll use a form, and we’ll animate the width of any form element that receives focus:

:focus 擬似クラスを使って、同様のことができます。今回はform要素を使いましよう。form要素にフォーカスが当たった場合に、幅をアニメーションさせてみました。

input, textarea {
  width: 280px;
  -webkit-transition: width 1s ease;
  -moz-transition: width 1s ease;
  -o-transition: width 1s ease;
  -ms-transition: width 1s ease;
  transition: width 1s ease;
}

input:focus, textarea:focus {
  width: 340px;
}

And here’s a live demo:

Transitions Using :checked

You can animate checkboxes and radio buttons when they become “checked” — although you’re limited with what you can do with those, since you can’t really change their native styling.

checkboxとradio buttonを”check”されたときに、アニメーションさせることもできます。ただしボタンに対してできることは限られています。何故ならnativeのスタイリングを変更することはできないからです。

We’ll just do a simple width change, which will appear to indent any selected checkbox:

シンプルな変更を加えてみることにしました。これによって選択されたチェックボックスは、インデントされたようになります。

input[type="checkbox"]:checked {
  height: 20px;
  -webkit-transition: width 1s ease;
  -moz-transition: width 1s ease;
  -o-transition: width 1s ease;
  -ms-transition: width 1s ease;
  transition: width 1s ease;
}

input[type="checkbox"]:checked {
  width: 30px;
}

And here’s a simple demo:

Transitions Using :disabled

Keeping with the theme of web forms, this time we’ll combine CSS3 transitions with some jQuery to animate the background color of form elements when they become disabled via the disabled attribute:

引き続きformを扱っていきます。今回は、CSS3 TransitionとjQueryを組み合わせて、formの背景色をアニメーションさせます。disabledアトリビュートによってdisableになった際にこれが発動するようにしました。

input[type="text"], textarea {
  background: #e2e2e2;
  -webkit-transition: background 1s ease;
  -moz-transition: background 1s ease;
  -o-transition: background 1s ease;
  -ms-transition: background 1s ease;
  transition: background 1s ease;
}

input:disabled, textarea:disabled {
  background: #666666;
}

And the quick-and-dirty jQuery that adds/removes the disabledattribute is:

そして非常に雑ではありますが、disabledアトリビュートをつけたり外したりするjQueryのコードは以下のようになります。

$(function() {
  $('input[type="radio"]').click(function() {
    if ($(':checked').val() === "other") {
      $('input[type="text"]').removeAttr("disabled");
    } else {
      $('input[type="text"]').attr("disabled", "disabled");
    }
  });
});

So when the last radio button is selected (the one with a value of “other”), the text box has its disabled attribute removed. If another option is selected, the disabled attribute is re-applied.

つまり、ラジオボタンの最後のものを選択すると(このボタンはotherというvalueを持っています)、テキストボックスはdisableといいうアトリビュートが鳥のどかれます。それ以外のラジオボタンが選択されると、disabledアトリビュートが再度適用されます。

The :disabled pseudo-class is dependent on that attribute being present, so the animation will occur whenever that attribute is added or removed.

:disabled 疑似要素は、現在のその属性がどのような状態であるかということに依存しますので、そのためアニメーションはそのアトリビュートが追加されたり削除されるときに、発動します。

Here’s the demo:

Transitions Using Media Queries

This last one may be the least practical, because let’s face it, the only people that ever resize their window to see what happens are web developers.

最後にとりあげるこのテーマはあまり実践的ではないかもしれません。というのも、ウィンドウサイズを変更して、何が起きるかをまじまじと観察するような人間は、ウェブディベロッパーくらいだからです。

Nonetheless, this is just another way to use CSS3 transitions. The new Modernizr design does this.

とにかく、このサンプルでは先程とは違った方法のCSS3 Transitonが使われています。新しいModernizrのデザインでもこれが使われています。

Here’s the code:

.box {
  width: 440px;
  height: 440px;
  background: #222;
  margin: 0 auto;
  -webkit-transition: width 2s ease, height 2s ease;
  -moz-transition: width 2s ease, height 2s ease;
  -o-transition: width 2s ease, height 2s ease;
  -ms-transition: width 2s ease, height 2s ease;
  transition: width 2s ease, height 2s ease;
}

@media only screen and (max-width : 960px) {
  .box {
    width: 300px;
    height: 300px;
  }
}

This example animates two different properties simultaneously, separating the two by a comma. The media query tells the box to shrink if the screen size goes below 961px.

上記の例では2つの異なるプロパティを同時にアニメーションさせています。それぞれの値はコンマで仕切られていますね。メディアクエリーはboxに、スクリーンサイズが961以下になった場合に、縮まるように定義されています。

Resize your window in the demo page to see it work:

Some Notes About the Code

If you’re wondering about the code, I’ve included the standard property last, even though it’s not supported by any browser that I know of.

どんなブラウザでも対応できるように、prefixとそれから標準的なプロパティを最後に追加しています。

Also, I’ve included the -ms- prefix, even though IE9 and IE10 do not yet support transitions. But evidently they are coming in IE10, so it’s worth including an extra line.

同じくprefixに関して。今はIE11が標準的に対応しなくてはいけないブラウザなので、ここは関係ない。

And the code examples that you can see in this post aren’t exactly the same as those used in the demo pages. I’ve made the code as brief as possible for the purpose of focusing only on the parts being discussed in this article.

デモコードは少し変えている。

Are There Other Ways?

This is pretty much all I could come up with for alternate ways to use CSS3 transitions. If you can think of another, let me know.

CSS3: Animations vs. Transitions

In CSS, you have two techniques for visualizing change that are competing for your attention: Animations & Transitions. In this article, let’s examine the similarities and differences between them so that you can know when to use which.

CSSにおいて、ユーザーの注意を引くための、視覚的な変化をもたらすための技術には、大きく分けて2つあります。一つはAnimationで、もう一つはTransitonです。この記事では、その2つの技術の同じ部分と異なる部分を精査していき、どちらを選択するばよいのか、その指針を示すことにします。

To make the most of this article, it would be helpful for you to be familiar with using both animations and transitions. If you haven’t had a chance to get your hands dirty with them, the Creating a Simple CSS Animation and Looking at CSS3 Transitions tutorials will help you get started.

この記事を最大限活用するためには、あなたが既にある程度AnimationとTransitionの技術に馴染みがあるほうがいいでしょう。実際に手を動かしてこれらの技術を使ったコードを書いたことがないのであれば、まずは上記2つのチュートリアルから始めるといいかもしれません。

Similarities

From a distance, both animations and transitions are very similar. They both allow you to:

大枠でいえば、animationとtransitionはどちらも非常に似ています。どちらも次のことができます。

  • Specify which CSS properties to listen for changes on
  • Set timing (easing) functions to alter the rate of going from a one property value to another
  • timing(イース)ファンクションを設定することで、プロパティの値の変化の進み具合を定義することが出来る。
  • Specify a duration to control how long the animation or transition will take
  • durationを設定することで、animatioやtransitionがどれくらいの時間をかけて変化するかを指定できる。
  • Programmatically listen to animation and transition-specific events that you can then do with as you wish
  • Visualize CSS property changes.

Beyond this point, though, you will see that animations and transitions diverge a bit and let their uniqueness shine through. Let’s look at those unique qualities in greater detail.

上記以外のことがらに関しては、animationとtransitionには少し違いがあり、その違いがお互いの良さを生じさせています。ではそれぞれの特質をより詳細にみていきましょう。

Differences

Animations and transitions show their differences when it comes to how you trigger them to play, whether they loop easily, how complicated of a transition you can define, how formal you must be in being able to use them, and how well they play with JavaScript. Let’s explore those topics in greater detail.

AnimationとTransitionの違いがはっきりと現れるのは、次のような点です。どのように開始のためのトリガーをするか。どれくらいループをさせることが簡単か。どれくらい複雑に変化を指定できるか。使用するためにどれくらい形式的な理解が必要か。そしてJavaScriptと組み合わせた時にどれくらい上手く動くか。ではこれらのトピックについて考えてみましょう。

Triggering

One of the major differences between animations and transitions can be seen in how you trigger them to start playing.

大きな違いの一つは、トリガーの方法です。どのように再生をスタートさせるか、という部分が異なります。

A transition only plays as a reaction to a CSS property that has changed. A common scenario is one where you use the :hover pseudo class to change the value of a CSS property:

Transitionは、CSSプロパティの変更に対してのみ反応し、再生をおこないます。よくあるのは、:hover擬似クラスを用いてCSSプロパティの値を変更する方法です。

To use the example visualized here, if a transition is defined, you would be able to see the circle growing from its normal size to its hover size. Another way of triggering a transition is to use JavaScript to programmatically add or remove CSS classes to simulate a CSS property change. Rounding out our ways of making a property change, you can use JavaScript to set an inline style that changes a property your transition is listening for.

上記の例を使って説明をします。transitionを定義しているので、通常のサイズからホバーしたサイズへと、円が大きくなっていくことが確認できます。ホバー以外の方法としては、JSを使ったプログラミングによってCSSクラスを追加したりすることでCSSプロパティを変更する方法もあります。つまりJSを使ってインラインスタイルに、プロパティを変更するような変更を加えます。しかもtransitionが待ち構えているプロパティを変更します。(訳注:「transiton: width 2s」となっている要素に対して、widthを例えばjQueryを使って$(‘.target’).width(400)と指定すればアニメーションする。)

Animations, on the other hand, don’t require any explicit triggering. Once you define the animation, it will start playing automatically. Yep, that’s how animations roll!

Transitionに対して、Animationの場合は、トリガーを明示的に宣言する必要はありません。一度アニメーションを定義してしまえば、自動的に再生されます。

Looping

This is pretty simple. Animations can be easily made to loop by setting the animation-iteration-count property. You can specify a fixed number of times you want your animation to repeat:

この話題に関して結論は非常にシンプルです。Animationはanimation-iteration-countプロパティを使うことで、簡単にループを設定することができます。アニメーションを繰り返す回数を具体的な数字で指定することができます。

animation-iteration-count: 5;

If you just want your animation to loop forever, you can do that as well:

無限にループさせた場合は、次のようにすることで実現できます。

animation-iteration-count: infinite;

Transitions, on the other hand, don’t have a property that specifies how many times they can run. When triggered, a transition runs only once. You can make a transition loop by fiddling with the transitionEnd event, but that isn’t particularly straightforward – especially when compared with animations.

それに対してTransitionの場合には、繰り返し何回も再生するように指定するpropertyはありません。トリガーされると、トランジションは一度だけ実行されます。transitionをループさせることは、transitonEndイベントを扱うことで実現できますが、しかしそれはあまり正攻法ではありません。とくにAnimationと比べた場合にはかなり複雑な方法です。

Defining Intermediate Points / Keyframes

中間点の定義 / Keyframeの場合

With an animation, you have the ability to define keyframes which give you more control over your CSS property values beyond just the start and the end:

Animationの場合、keyframeの定義によって、CSSプロパティの値をよりコントロールすることができ、開始と終了以上の定義ができます。

You can set as many keyframes as you want, and when your animation plays, each keyframe will be hit with the specified property changes reflected. This allows you to create the kinds of involved animations that help HTML5 compete with more established animation technologies like Flash more effectively.

keyframeは望む数だけ、何個も設定できます。アニメーションがスタートすると、それぞれのkeyframeの位置で指定されたpropertyの変更が反映されます。これによってHTML5で、他の洗練されたFLashのようなアニメーション用のテクノロジーに、匹敵する効果を作り出すことができます。

With a transition, you don’t have much control over anything beyond the end result:

Transitionでは、最初と最後の指定以上の、複雑なコントロールはできません。

A transition simply goes from an initial state to the final state. You cannot specify any points in-between like you can with an animation, so a transition might not be a good choice if you are trying to create the next Teen Girl Squad sensation or a complex animation.

Transitionは単純に、初期状態から、最終的な状態へと、推移させることしかできません。keyframe animationのように、中間点を指定することはできないのです。なのでtransitonでは、Teen Girl Squadのような刺激的で複雑なアニメーションを作るのには向いていません。

Specifying Properties Up-Front

The next thing I will describe is how formal animations and transitions are when it comes to defining a transition between CSS property values.

次の話題は、どれくらい規則だった定義が、アニメーションにおいて必要か、という観点です。

On the formal side, you have transitions. Every CSS property you want recognized by your transition must be explicitly represented.

もし規則だった書き方をしたいのであれば、Transitionに軍配が上がるでしょう。Transitionに反応して欲しい全てのCSSプロパティを、明示的に書く必要があります。

For example, let’s say you have something like the following:

例えば、以下のようなコードを書いたとしましょう。

#mainContent { 
        background-color: #CC0000; 
        transition:background-color .5s ease-in; 
} 
#mainContent:hover { 
        cursor: pointer; 
        background-color: #000000; 
        width:500px;
}

Upon hover, I specify a different value for both background-color as well as width. My transition specifies only background-color though. This means your browser is only listening for changes on the background-color property.

hoverした場合には、通常時とは異なる2つのプロパティの値を指定しています。バックグランドカラーと幅です。ただし、Transitionではバックグランドカラーだけを指定しています。つまり、バックグラウンドカラーの変更だけを、監視することになります。

If I wanted my transition to affect both the background-color and width properties, I will need to explicitly add another transition entry for width:

もしバックグラウンドカラーとwidthの2つのプロパティをトランジションしたい場合には、明示的にwidthもtransitionに加える必要があります。

#mainContent { 
        background-color: #CC0000;
        transition:background-color .5s ease-in, width .5s ease-in 
} 
#mainContent:hover { 
        cursor: pointer; 
        background-color: #000000; 
        width: 500px;
}

What About transition: all?

全てのプロパティをトランジションする場合にはどうすればよいか

You do not have to specify every property that you care about when using a transition. You could simplify your life by using the all value instead: transition: all .5s ease-in. I do not recommend this because you will take a performance hit. Your browser is now listening for a whole lotta properties as opposed to just a few that you know you will be modifiying. Unless you have a strong need to do this, I would recommend specifying each CSS property you wish to transition individually.

Transitionを使う際に、全てのプロパティを明示的に指定する必要はありません。allという値を代わりに使えば、シンプルに全てのプロパティををトランジションさせることができます。「transition: all easein」といった具合です。とはいえ、これはあまりおすすめしません。何故ならパフォーマンスが下がるからです。こうした場合、ブラウザは沢山存在する全てのプロパティを監視するからです。それなのにあなたが変更するプロパティは少ししかありません。こうすべき強い必要性がない限りは、transitionさせたいプロパティをそれぞれ指定することをおすすめします。

With animations, you have the ability to specify properties at a whim in each keyframe without having to do anything that resembles declaring them:

Animationにおいては、以下のようにすればいいです。

keyframes imageSlide { 
        0% { 
                left: -150px;
        } 

        20% { 
                left: 50px; 
                height: 200px;
        } 

        80% { 
                left: 200px; 
                height:300px;
        } 

        100% { 
                left: 600px; 
                background-color:#FFFFFF;
        } 
}

In this example, the height and background-color of whatever element I am animating will smoothly transition when the appropriate keyframe is reached – even if the property was never listed before!

このように、適切なアニメーションが各keyframeで発動します。そために、前もって変更するプロパティのリストを作っておく必要はありません!

Interaction with JavaScript

In many cases, a transition or animation you declare in CSS will be good enough. You specify in CSS your starting value, the ending value, and any intermediate values that you want your properties to take. Your animation or transition will read these values and take care of business from there. This scenario works best when what you are wanting to do is predefined. There will be times when you want to alter the value of a property that you are animating based on some external input – a mouse click, the result of some calculation, etc.

多くの場合において、CSSで実装するtransitionやanimationといった機能は、それだけで十分な役割を果たしてくれます。CSSで開始時の値を定義して、終わりの値も定義して、そして中間点を定義して、といった具合に。AnimationやTransitionはそれらの値をしっかり読み取って、それぞれの地点で自分の仕事を遂行します。どうしたいかが事前に決まっている場合には、これで役割をしっかりとこなすことができます。しかし、値を、外部の入力値に基づいて、アニメーションを変更したい場合もあるでしょう。例えばマウスクリックや、ある種の計算の結果を使用する場合です。

For such interactions, property values entirely predefined in CSS is a bit limiting. You can decide in such cases to rely on JavaScript, but going all-in on JavaScript alone may be too extreme as well. What you want is a hybrid approach where your animation or transition is declared primarily in CSS but certain aspects of which are manipulated using JavaScript.

このようにインタラクションが必要な場合には、CSSに予め記述された値だけでは、できることが限定されてしまいます。そういった場合には、JSを使用することを検討すると思いますが、かといって全てJSだけで実装するのはやりすぎだというようなケースがあります。そういう場合には、CSSアニメーションとJSのハイブリッドというアプローチも選択肢に入るはずです。animationやtransitionで予め大部分をCSSにかいておいて、しかしある部分はJSで操作する、といった方法です。

When it comes to combining JavaScript with either an animation or transition, there is no contest – you almost always want to use a transition. Using an animation with JavaScript is possible…in much the same way it is possible to win at the cinnamon challenge. It isn’t impossible to make it work, but chances are, you don’t want to do it. The reason for this difference has to do with how transitions and animations work.

JSと組み合わせるという観点から言うと、はっきりいって勝負は見えています。ほとんどのケースでは、transitionを使うことになるでしょう。Animationを使う方法も無理ではないのですが、そうしようと思う機会はかなり少ないはずです。その理由は、transitionとanimationの挙動に違いがあるからなのです。

Animations are very specific in what they do. The @keyframes rule clearly lays out the path your animation will take as it is running. Attempting to change your animation in JavaScript requires a very complicated series of steps that involves actually modifying the @keyframes style rule itself. If you’ve ever had to manipulate CSS that lives inside a style rule, you know that it is pretty unintuitive.

Animationの場合は、何をするのかということをかなり具体的に定義します。@keyframeによってアニメーションがどのような状態を変遷していくのかを、明確に定義します。JSによってアニメーションを変更しようとすると、かなり複雑な作業が必要になります。@keyframesを書き換えないといけないからです。インラインで記述されたCSSをマニュピレイトしたことがある人ならわかると思いますが、これはかなり直感的ではありません。

Contrasting the predefined path of an animation is the transition. Transitions are not as well defined as they may seem. Your transition will kick in when a property it is listening for changes. This property change can be set entirely via only CSS:

Transitionの場合は、そこまで定義をしていません。トランジションは、待ち受けていたプロパティの変更があった場合に、開始されます。下記のコードではプロパティの変更はCSSの中でなされていますね。

#myElement {
        background-color: #FFF;
        transition: background-color .2s ease-in;
}
#myElement:hover {
        background-color: #000;
}

This change can also be accomplished via JavaScript where you modify a CSS property the transition is listening for by setting an inline style:

CSSプロパティの変更はJSからも可能です。インラインに書かれたトランジションが待ち受けるプロパティを、JSから変更しましょう。

var myElement = document.querySelector("#myElement");
myElement.style.backgroundColor = "333";

The transition doesn’t care how the properties it is listening for changes. As long as the property changes somehow, the transition will get to work. This means, for interactive scenarios that don’t involve a predefined starting and ending point, you can do a lot of interesting things by deferring all transition-related heavy lifting by using the transition declaration. The actual values of the properties you are wanting to transition can be specified using JavaScript.

transitionは、変更を監視しているプロパティがどんな方法で変更されるかは、まったく気にしていません。とにかくプロパティが変更されれば、Transitionが発動します。つまり、予め始まりと終わりが決まっていないインタラクティブなアニメーションを実装する場合に、transtionの対象になっているプロパティを変更することで、様々な面白い効果を得られる、ということです。望むプロパティの値をJSを使って指定することができます。

To help visualize what I just wrote, let’s look at a simple example:

Click anywhere in the gray box to have the circle move to the point of the click. Keep clicking around to see the circle keep moving.

灰色のboxの中でクリックすると、円がその場所に移動します。クリックして、円が移動するのを確認してください。

How this works is pretty simple. The actual movement is handled by the transition. Knowing where to transition to is handled by the JavaScript which sets the top and left property values on the element. Because the transition is listening for changes to the top and left properties, any change results in your transition kicking in. The end result is exactly what you wanted. Best of all, you didn’t have to write any JavaScript for handling the actual movement itself. As a bonus, because the transition is declared in CSS, your browser optimizes it heavily so that it runs really smoothly.

仕組みは非常に簡単です。実際の動きは、transitionによって実装されています。どこへ移動すべきなのか、ということはJSを使って制御されています。JSによってtranstionが監視している、leftプロパティとtopプロパティを変更しています。変更が発生すると、transitionが起動します。その結果希望する結果を実現しています。一番いいのはJSを全く書かないで実装する方法ではありますが。副次的な利点としてtranstionはCSSで宣言されているので、ブラウザーはパフォーマンスを最大化してくれ、結果として非常にスムーズに動きます。

This friendship between transitions and JavaScript is so full of win, it hurts just writing about.

transitionとjsの組み合わせは、非常に有効です。

Conclusion

There you have it – a candid look at what makes transitions and animations similar yet so very different. My general approach for determining when to use which goes like this:

TransitionとAnimationが基本的には似ていて、それでいて異なる部分もかなりある、ということをみてきました。どちらを使うべきなのか、ということに関しての私の選択基準は、以下の様なものです。

  • If what I want requires the flexibility provided by having multiple keyframes and easy looping, then I go with an animation.
  • keyframeと簡単に実装できるループによる柔軟性が欲しいときは、animationを選択します。
  • If I am looking for a simple from/to animation, I go with a transition.
  • シンプルに、開始と終了を設定するアニメーションを実装した場合にはtransitionを選択します。
  • If I want to manipulate the property values that I wish to animate using JavaScript, I go with a transition.
  • JSでプロパティの値を操作したい場合には、Transitionを選択します。

Now, with enough effort and JavaScript tomfoolery, you can neutralize any deficiences I list in deciding whether to use a transition or an animation. My recommendations are based on the common cases where you take a transition or animation mostly at face value. Herculean efforts to change their default behavior is admirable but often unnecessary.

もちろんJSで色々とがんばれば、どちらの機能を選択するか、を検討する際にあげたそれぞれの欠点を埋め合わせることはできます。しかし、一般的なケースにおいては上記のような選択をするのが普通でしょう。必死の努力によってこれら二つの機能の基本的な振る舞いを変更することはできますし、それは賞賛に値するのかもしれませんが、意味はありません。

日本語訳: Presentational and Container Components

勝手に翻訳シリーズ

元の記事

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

Presentational and Container Components

Bismuth
There’s a simple pattern I find immensely useful when writing React applications. If you’ve been doing React for a while, you have probably already discovered it. This article explains it well, but I want to add a few more points.
とても有益でシンプルなパターンを、Reactを書いているときに見つけました。もちろんあなたもReactをある程度書いたことがあれば、多分同じようなことを既に発見されていることでしょう。Thisこの記事も同じことについて説明しています。ですが、さらにいくつか新しいことを紹介できるとおもいます。
You’ll find your components much easier to reuse and reason about if you divide them into two categories. I call them Container and Presentational components* but I also heard Fat and SkinnySmart and Dumb, Stateful and PureScreens and Components, etc. These all are not exactly the same, but the core idea is similar.

ご存知だと思いますが、コンポーネントをうまく再利用するためには、そしてうまく整理するためには、コンポーネントを2種類に切り分けると良いのです。その二つを私はContainer ComponentとPresentational Componentと名付けることにしました。ですが人によってはFatとSkinny、SmartとDumb、StatefulとPure、ScreensとComponentsと、様々な呼び方をしています。これらは全てが完全に同じものではありませんが、中心的な役割は同じです。

My presentational components:

私がPresentationalと名付けたコンポーネントの特徴は以下の通りです。

  • Are concerned with how things look.
  • どのような見た目になるか、ということと関連づいている
  • May contain both presentational and container components** inside, and usually have some DOM markup and styles of their own.
  • PresentatinalコンポーネントとContainerコンポーネントの両方を内部に持つことができ、たいていの場合は自分自身のためのDOMマークアップとスタイルを持つ。
  • Often allow containment via this.props.children.
  • たいていの場合は、コンテンツをthis.props.childrenを用いて保持している。(訳注:公式参照 コンポーネントの<Component>ここ<Component>ここの部分入れらたものがthis.props.childrenで参照できる部分。通常、これは自動的にレンダリング時に参照され、内部で保持され、表示される。)
  • Have no dependencies on the rest of the app, such as Flux actions or stores.
  • アプリケーションの他の部分に対して依存している部分が一切ない。例えばFluxのactionやstoreに依存している部分がない。
  • Don’t specify how the data is loaded or mutated.
  • dataがどのようにロードされるか、もしくは変更されるか、といったことは定義しない。
  • Receive data and callbacks exclusively via props.
  • dataやコールバックは外部からprops経由で受け取る。
  • Rarely have their own state (when they do, it’s UI state rather than data).
  • 独自の状態を保つことは基本的にはない。(あるとすれば、UIの状態を持つ場合であってDateではない。)
  • Are written as functional components unless they need state, lifecycle hooks, or performance optimizations.
  • Functional コンポーネントとしてかかれる。状態やライフサイクルフック、パフォーマンス調整が必要とされない限りは。
  • Examples: Page, Sidebar, Story, UserInfo, List.
  • 例としては、Page, Sidebar, Story, UserInfo, Listなどがあげられる。

My container components:

私がContainerと名付けたコンポーネントの特徴は以下の通りです。

  • Are concerned with how things work.
  • どのように機能するか、ということと結びついてる。
  • May contain both presentational and container components** inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
  • PresentatinalコンポーネントとContainerコンポーネントの両方を内部に持つことができるが、たいていの場合は自分自身のためのDOMマークアップとスタイルを「持たない」。
  • Provide the data and behavior to presentational or other container components.
  • データと挙動を、Presentationalコンポーネントや、他のContainerコンポーネントに対して提供する。
  • Call Flux actions and provide these as callbacks to the presentational components.
  • Fluxのアクションをcallしたり、アクションをコールバックとしてPresentatinalコンポーネンへ提供する。
  • Are often stateful, as they tend to serve as data sources.
  • たいていの場合は状態を持ち、データの源としての役割を担う。
  • Are usually generated using higher order components such as connect()from React Redux, createContainer() from Relay, or Container.create() from Flux Utils, rather than written by hand.
  • higher order componentを用いることで生成される。例えばReact Reduxのconnect()やRelayのcreateContainer()やFlux UtilsのContainerCreate()である。
  • Examples: UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

I put them in different folders to make this distinction clear.

私はこの二つのコンポーネントを、異なるフォルダーに配置することで、明確に区別することにしています。

(訳注:ということは、Reduxのconnect()を使う層は、基本的にContainer Component。connectはなぜ使うかといえば、state,reducer,actionとpresentationalコンポーネントを、Containerコンポーネント内で結びつけるため。presentationalコンポーネントとactionをロードして、connectでstate,dispatchと結びつける。するとpresentationalコンポーネントにstate,dispatchが渡されるので、presentationalコンポーネントがそれを使えるようになる。connectで結びつけて作った新しい高次階層コンポーネントをexportし、これを他のコンポーネントから呼び出して使う。)

Benefits of This Approach

このアプローチの利点

  • Better separation of concerns. You understand your app and your UI better by writing components this way.
  • 役割の分割をうまくできる。コンポーネントをこう書くことで、アプリケーションとUIがどうなっているのか、より理解しやすくなる。
  • Better reusability. You can use the same presentational component with completely different state sources, and turn those into separate container components that can be further reused.
  • 使い回しが効く。Presentationalコンポーネントを全く異なるStateを持つ状況において使用することができる。また異なるContainerコンポーネントの中で使用することができる。
  • Presentational components are essentially your app’s “palette”. You can put them on a single page and let the designer tweak all their variations without touching the app’s logic. You can run screenshot regression tests on that page.
  • Presentatinalコンポーネントは、本質的にはアプリケーションの「パレット」である。ページのどこにでも配置することができ、デザイナーがアプリのロジックに触ることなく変更することができる。
  • This forces you to extract “layout components” such as Sidebar, Page, ContextMenu and use this.props.children instead of duplicating the same markup and layout in several container components.
  • こうすることで「layout Component」を強制的に取り除くことになるので、同じマークアップやレイアウトを様々なContainerコンポーネントになんども複製する必要がなくなる。this.props.childrenを使えばいい。

Remember, components don’t have to emit DOM. They only need to provide composition boundaries between UI concerns.

コンポーネントは必ずしもDOMを出力する必要はない、という点に注意してください。第一の役割は、コンポジションにおける境界を定義することにあります。

Take advantage of that.

どの段階でContainerを導入すべきか

When to Introduce Containers?

I suggest you to start building your app with just presentational components first. Eventually you’ll realize that you are passing too many props down the intermediate components. When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree.

まずはPresentationalコンポーネントだけでAppを書き始めることをお勧めします。そうしていくと、最終的には、あまりに多くのpropsを中間層のコンポーネントに渡している、と感じることにはなると思います。propsを受け取ってはいるものの、用いておらず、単にさらに下部のコンポーネントへと渡しているだけのコンポーネントがあるような状況が生まれた場合が、Containerコンポーネントを導入するのに最適な段階でしょう。そうすれば、データや挙動のためのpropsを各コンポーネントに与えるために、関係のないコンポーネントを中間層に挟む必要がなくなります。

This is an ongoing process of refactoring so don’t try to get it right the first time. As you experiment with this pattern, you will develop an intuitive sense for when it’s time to extract some containers, just like you know when it’s time to extract a function. My free Redux Egghead series might help you with that too!

これはリファクタリンの際に継続的におこなうことなので、最初から行う必要はありません。このパターンで書く際に経験していることだと思いますが、いつコンテイナーを導入するのかということを感じ取るセンスを育む必要があります。これはちょうど、どの段階でFunctionにまとめるべきなのかを判断するセンスと似ています。 free Redux Egghead series も参考になるはず!

他の違い

Other Dichotomies

It’s important that you understand that the distinction between the presentational components and the containers is not a technical one. Rather, it is a distinction in their purpose.

presentationalコンポーネントとcontainerコンポーネントの違いは、技術的なものというよりは、その目的による、という点を理解することが重要です。

By contrast, here are a few related (but different!) technical distinctions:

  • Stateful and Stateless. Some components use React setState() method and some don’t. While container components tend to be stateful and presentational components tend to be stateless, this is not a hard rule. Presentational components can be stateful, and containers can be stateless too.
  • Stateful and Stateless.  ReactのsetState()を使うコンポーネントもあれば、使わないコンポーネントもあります。ContainerコンポーネントはStateを持つ傾向にあり、Presentationalコンポーネントがstateを持たない傾向にありますが、とはいえこれは厳密なルールではありません。Presentationalコンポーネントがstateを持つこともありますし、ContainerコンポーネントがStateを持たないこともあります。
  • Classes and Functions. Since React 0.14, components can be declared both as classes and as functions. Functional components are simpler to define but they lack certain features currently available only to class components. Some of these restrictions may go away in the future but they exist today. Because functional components are easier to understand, I suggest you to use them unless you need state, lifecycle hooks, or performance optimizations, which are only available to the class components at this time.
  • Classes and Functions. React 0.14から、コンポーネントはクラスとしてもファンクションとしても宣言できるようになりました。ファンクショナルコンポーネントは宣言がよりシンプルですが、クラスコンポーネントにしかない機能を持っていません。そういった制限が将来撤廃されるかもしれませんが、今のところは存在します。ファンクショナルコンポーネントは把握するのが簡単ですので、ステイト/ライフサイクルフック/パフォーマンスの調整といったクラスコンポーネントだけにしかない機能が必要でない場合には、ファンクショナルコンポーネントを使うことを推奨します。
  • Pure and Impure. People say that a component is pure if it is guaranteed to return the same result given the same props and state. Pure components can be defined both as classes and functions, and can be both stateful and stateless. Another important aspect of pure components is that they don’t rely on deep mutations in props or state, so their rendering performance can be optimized by a shallow comparison in their shouldComponentUpdate() hook. Currently only classes can define shouldComponentUpdate() but that may change in the future.
  • Pure and Impure. コンポーネントのうち、同じpropsと状態を与えれば、同じ結果を返すものを、Pureコンポーネント、と言ったりします。ピュアコンポーネントは、クラスでもファンクションでもどちらでも定義することができます。またステイトを持つことも持たないこともできます。(残りの部分わからず)

Both presentational components and containers can fall into either of those buckets. In my experience, presentational components tend to be stateless pure functions, and containers tend to be stateful pure classes. However this is not a rule but an observation, and I’ve seen the exact opposite cases that made sense in specific circumstances.

PresentationalコンポーネントもContainerコンポーネントも、そうではないもう一方のコンポーネントになる可能性が常にあります。私の経験では、Presentatinalコンポーネントはstatelessなピュアファンクションであり、Containerコンポーネントはstateを持つピュアクラスであることが多いようです。とはいえこれはルールではなくて、あくまでもそういうことが多いというだけなので、過去には全くの反対のケースで、しかも合理的、という状況もありました。

Don’t take the presentational and container component separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. If you feel unsure about whether a specific component should be presentational or a container, it might be too early to decide. Don’t sweat it!

PresentationalコンポーネントとContainerコンポーネントの区別を、教義のように考えないようにしてください。時にはそんなことを考える必要がない時もありますし、区別をすることが難しい場合もあります。どちらにすべきか確信が持てない場合には、それを決断するにはまだ早いのかもしれません。そんなことは気にしないで!

Example

This gist by Michael Chan pretty much nails it.

Further Reading