>>300の例では、return valueと単なる値を返した、
単なる値を返すと、次のthenの引数になるが、
単なる値の代わりにPromiseオブジェクトを返すこともできる

function newPromise() {
return new Promise(function (resolve, reject) {
　resolve('new-promise');
});
}

asyncFunction()
　.then(function (value) {
　　console.log(value); // => 'Async Hello world' ・・・(1)
　　return newPromise(); // 参考 return Promise.resolve('new-promise') と書いても良い
　}).then(function (value) {
　　console.log(value); // => new-promise' ・・・(2)
　　return value;
　});


この場合、2番目のthenの関数の引数には、Promiseオブジェクトが渡されるのではなく、
Promiseでresolveされた値（new-promise）が渡される

もしnewPromiseがresolveするまでに時間がかかる場合は、
2番目のthenが呼び出されるまで時間がかかるということ
thenで単なる値を返した場合は、次のthenはすぐに実行される。
すぐにresolveされたのと同じだと考えればいい

このように、thenでreturnするのは単なる値でもPromiseオブジェクトでも良いという
仕様のために、Promiseを返さない単なる関数をあとからPromiseに変えても
同じように動かすことができる。同期と非同期の違いを吸収していると考えることができる。

>>290でreturnしない場合、

asyncFunction() ・・・(a)
　.then(function (value) {
　　console.log(value); // => 'Async Hello world' ・・・(1)
　　asyncFunction() ・・・(b)
　}).then(function (value) {
　　console.log(value); // => undefined ・・・(2)
　})


(a)のasyncFunction()につながってるthenの結果として
(1)と(2)のconsole.logが実行される。
(2)のconsole.logがundefinedなのは間違いではない。
なぜならthenでreturnしてないのだから当然undefinedになる

(b)のasyncFunction()は何の意味も持たない。なぜなら(b)がresolveしても
その後にthenがないので(b)の結果としては何も出力しない

returnした場合は意味が異なる。(a)の1番目のthenの戻り値はPromiseオブジェクト
そのため(b)がresolve()された後にresolve()された結果が２番めのthenに渡される。

asyncFunction() ・・・(a)
　.then(function (value) {
　　console.log(value); // => 'Async Hello world' ・・・(1)
　　return asyncFunction() ・・・(b)
　}).then(function (value) {
　　console.log(value); // => 'Async Hello world' ・・・(2)
　})

注意として(1)のvalueと(2)のvalueは（同じ文字列だが）違うオブジェクト
(1)は(a)がresolve()された結果だが、(2)は(b)がresolve()された結果

>>290の

> 以前も別件でfoo.map( ( x ) => x*2 )を
> foo.map( ( x ) => { x*2 } )と書いてしまい、returnでハマりました。

これは単純な勘違いをしているだけ
{ } を省略したら return も省略できる
{ } で囲んだら return が必須
というだけの話

個人的にはアロー関数は、関数っぽく見えないのも利点の一つだと思ってるので
前者の書き方をおすすめする。 { } をつけて returnを書いて、ましてや { } の中に
複数の式や文を書くのはなんか違うと思ってる

>>287
これ何に描画してんの？

>>303
ありがとうございます。自分の納得は低レベルでした。
めちゃくちゃわかりやすかったです。精進します。

>>303
お前それforEachさんの中でもおんなじこと言えんの？

forEachとか使わないな。
普通はmapとか使う

個人的にforEachは名前をforやeachにしなかったのが結構な失敗だと思ってる

>>307
普通って何よ。お前の普通なんて知らんがな。
javascriptで副作用だけ使いたい場面なんていくらでもあるだろう。
console.log使って例示すると、
['foo', 'bar'].forEach(item => {
console.log(item);
});
map使うってお前…これをお前は
['foo', 'bar'].map(item => console.log(item));
と書くのか？
[undefined, undefined]なんて生成してなんに使うの？
なんでもかんでもmapはダメだろ。それぞれ想定されてる用途がある。
あとアロー関数の{}にreturn必須とか嘘教えんな。

複数の文を書くなと言うのもどういうことだ。
ちょっとしたcompare function書くとき、読みやすさや入力値チェック処理などで複数行になったらアローじゃなくてfunction(){}使えってこと？
どんなオレオレルールだ。わけの分からない縛りいれるのならアロー関数なんてやめたら。
['大', '小', '小', '中', '中', '大'].sort((a, b) => {
const order = ['小', '中', '大'];
return order.indexOf(a) > order.indexOf(b);
});

普通こうやるからなぁ

console.log(['foo', 'bar']);

おじいちゃん、配列の要素をそれぞれログするのと配列をそのままログするのは違うでしょ。
前者は
foo
bar
後者は
[ 'foo', 'bar' ]
になるでしょ。
ロシアのえんぴつ的なことが言いたいならそもそもブラウザのデベロッパーツール使えばいいでしょ。
でもそういう話じゃないから。

まあ普通にこうかくだろうな
何度もconst order = ・・・を実行するのは無駄だし

const order = ['小', '中', '大'];
const data = ['大', '小', '小', '中', '中', '大'];
data.sort((a, b) => order.indexOf(a) > order.indexOf(b));

>>312
ごもっともな指摘。
もっとちゃんとした例考えないとな…

ちなみに最後の
data.sort((a, b) => order.indexOf(a) > order.indexOf(b));
は、order.indexOfを二回書くの無駄だと思わね？

lodash使うとこう書ける
_.sortBy(data, v => order.indexOf(v));

へぇー思想違うんだなぁ。
考えてみてもこの仕様で困る例が思い付かない。
素のsortでは表現できてlodashのsortByでは無理な比較仕様ってあるのかな

思想？ 違いがあるとしたら
まあ何かやりたいことがあって、それを実現するためには
どういうふうに処理したらいいか？と考える人と
やりたいことがそのままコードになってないと気がすまない人の違いかな

俺は「文字の小さい順に並び替えたい」と思ってるから
コードには「文字」「大小を求める」「並び替える」この３つぐらいしか
登場してほしくないんよ。人間の思考の通りのコードになって間違いが少なくなる

一方で、並び替えるには文字と文字をそれぞれ数値化したものを比較する関数を
ソート関数に渡せば実現できるという、やりたいことを処理に置き換えてからコードにするやつもいる
処理を考えてしまうから、こっちのやり方では冗長化してしまうんだよ。それが困ることだな

>>316
あれは何に描画してんの？

>>315
あり得そうな気がするが、相当なレアケースじゃないかな。事実上困らない

複数の値で比較したい場合はどうすんの？

>>319
こういうこと？

http://lodash.com/docs/4.17.4#sortBy

var users = [
{ 'user': 'fred', 'age': 48 },
{ 'user': 'barney', 'age': 36 },
{ 'user': 'fred', 'age': 40 },
{ 'user': 'barney', 'age': 34 }
];

_.sortBy(users, ['user', 'age']);
// => objects for [['barney', 34], ['barney', 36], ['fred', 40], ['fred', 48]]

ライブラリ使う必要ない場面で
ここでしか見ないナントカってのを執拗に勧めるやつまだいたのか
害悪だなぁ

ここでライブラリを使うって事は間違ってないと思うよ
ただsortByっていう名前での
結局ライブラリを覚えないと自明ではない振る舞いは好きじゃないし
それがこの一時で便利だとは思わない

さよかｗ

>>322
sort by というのは例えばRuby標準にも有るしよく知られた単語なんだよ

プログラマにとって、for といえば ループねって
わかるように、sort by というだけで何をするのか知ってるもの

それに対して、オレオレライブラリで勝手な名前を作ると困る
それが何をするのかわからない

同じ覚えることでも、一般的なものを覚えるのと
プロジェクト固有のものを覚えるのとでは、覚える価値が違う

lodashはよく知られたアルゴリズムをよく知られた名前で実装してるので
覚える価値が高い。たとえ使わなくても知っておいたほうが良いものばかりだよ

他の言語にあるって然程重要では無いと思うけどね
特に補完が弱い動的型付け言語のJSでは
いかに他のJS周りの標準と命名規則を揃えて
振る舞いや型を想像付かせるかが大事

JSにsortByのような文化は無いのだから
なんぼRubyやらにそれがあると言われても
多くのJSerはローダッシュのsortByと覚えることになるのよ

>>319-320
Kotlin なら

Kotlin 2
http://mevius.5ch.net/test/read.cgi/tech/1509462463/18

>>325
> JSにsortByのような文化は無いのだから

世界が狭いな。
あんたはJSの世界に生きてるわけか

俺はプログラマの世界に生きてるんだよ。
JSはそのプログラマの世界の一地域にすぎない

俺様の世界ｗ

>>327
それは日本人に会った時世界の挨拶だからと言ってハグするようなもんだぞ

>>329
それは的はずれだな。

今言ってる世界っていうのは、広さの話をしてる
JSの世界っていうのはプログラマの世界の一部

プログラマの世界も狭くね？

>>331
今は相対的な話をしているので、
プログラマの世界よりも○○の世界が広い言い方をしてくれない困る
そして○○が話と全く関係ない世界だとそれは意味がない

JSerの価値観っていう話でさえ既に十分に大袈裟で広い話なのに
JS質問スレにプログラマの世界（しかも一部の>>327が好きな言語限定）とか持ち込まれてもな

好きな言語限定？

いろんな言語の知識を持っていると
好きな言語以外の話も持ち込むよ？

本当にあんた世界が狭いねｗ

すんごく初歩的なことで申し訳なさでいっぱいなんですが教えて下さい

clickイベントリスナをつけた<button>や<input>があって
これをdisabled="disabled"やelement.disabled = trueでdisabledにしたとき
<button>や<input>をclickしてもイベントは発火しない

これ合ってます？この挙動普通？

>>334 見てて恥ずかしい奴だな もう口を開くな

>>336
断るｗ いくらでも言うよ？見たくない、聞きたくないなら、
俺に何かをさせるんじゃなく、あんたが自分で行動しなきゃだめだよ

自演しつけえ
お前が低レベルなことはみんなわかってるからw

みんなって誰？
一人何役してるの？

>>321-325,327-334,336,337,339
とりあえずこれ全部低レベルな１人の自演

はい、はずれｗ

それはいいからどこが低レベルなのか
その理由を言ってみたら？
言えなきゃ言えないやつが低レベルってことだし

>>340
君って俺様の世界なんだよねｗ

なぜ自作自演だって見抜いただけで
俺様の世界ってことになるのか？

ばれて必死になりすぎ

>>343
自演なんだろ？お前の中ではな
って言えば理解できるかい？

俺様の世界のグローバル化

アジアではこういう考え方が主流なんだから狭い価値観に捕われるなって言うのと
その前にここは日本人による日本人のためのスレなんだから日本の考え方を深く学ぶべきって言うのと
アジア基準が常識とか中途半端で恣意的な価値観だなっていうヤジの３つに分けれてる

質問スレなんだから質問とそれに対する回答だけでいいんだよ
考え方とかどうこうはいらない
自分の考え方と違うなら「こういうやり方もあるよ」と自分なりの答えを書けばいい
どれを採用するかは質問者の自由

つまり自分なりの考えを書くんですね？

「考え」は書くな
「答え」を書け
ただし質問に書いてもいないライブラリやフレームワーク持ち出すのはただのバカだからNGだろ