+ JavaScript の質問用スレッド vol.136 +
レス数が950を超えています。1000を超えると書き込みができなくなります。
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」から解離した議論はよそでやること。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです データ
2017〜2018年に突如出現したReactは
2018年の間にシェアを大きく減らした
2018年は、脱Reactの年だった。オワコンReact
Usage Trend
https://w3techs.com/technologies/history_overview/javascript_library/all/y
React： 2017年1月 なし、2018年1月 0.5%、2019年1月 0.2%
Market Share Trend
https://w3techs.com/technologies/history_overview/javascript_library/ms/y
React： 2017年1月 なし、2018年1月 0.7%、2019年1月 0.2%
※2019年1月は正確には2018年12月27日現在のデータ >>889
反論来ても問題ないように、いつから増えたかは言っていない
どれぐらい増えたかは自身で示されればいいんじゃないすうかｗ >>888
あぁわかった
彼に話が通じない理由
スマホアプリの開発経験がないんだね
だからHTMLで構成されたwebアプリケーションをそのままスマホアプリ化できることをしらない
レスポンシブデザインがwebブラウザ上でしか使われていない、スマホアプリとは無関係な技術だと勘違いしてるのか
道理で平行線なわけだ 反論来ても問題ないように、いつから増えたかは言っていない
＝反論されたら言い返せないから、はぐらかすために言ってない。
＝でもデータ示せとくるのは想定外だった。だから聞かれても言わない（答えられない）
やっぱりウゾじゃないですかーｗ > スマホアプリの開発経験がないんだね
> だからHTMLで構成されたwebアプリケーションをそのままスマホアプリ化できることをしらない
え？無理だよ 有名な話なのにねー
AirbnbがReact Nativeを諦めてネイティブアプリに方向転換したわけ
https://medium.com/@Roy_S_Kim/airbnb%E3%81%8Creact-native%E3%82%92%E3%82%84%E3%82%81%E3%81%9F%E3%82%8F%E3%81%91-802589f4ff44
うまくいってなかったこと
> JavaScriptCoreがプラットフォームごとに異なるので、
> それを原因とする問題のデバッグが大変。これも一回ハマると相当時間がかかる。
> ほとんどのエンジニアはiOSかアンドロイドのどちらかの環境には詳しいけど、
> 両方を熟知している人は少ない。React Nativeのオープンソースのライブラリは
> そのような人々によって作られている。結果的に安心して使うことはできない。テストも大変。
> 最初にレンダーリングする時にランタイムの初期化に数秒もかかる。
> アプリサイズが大きくなる。
> 複雑なジェスチャーが使えない。
> よくある勘違いはReact Nativeを使うとネイティブコードを書かなくて済むということだが、
> 現実はそうではない。品質のいいアプリを作るにはネイティブコードと
> React Nativeのコードのバランスを慎重に検討する必要がある。
> デバッグをする際にはネイティブコードを深追いしないといけない場合があるので
> ネイティブ開発の知識は必要。また、React Nativeとネイティブのどこをみれば
> いいかを判断することも容易ではない。結果的にエンジニアは全てのプラットフォームと
> React Nativeの知識を学習する必要がある。 まだクロスプラットフォームでできるという
理想を信じてるやつがいるのか？
結局ユーザーインターフェースは各プラットフォームごとに
用意しないとだめだって結論出てるだろ >>896
Airbnbの数倍以上の規模があるFacebookアプリで使われてるからそういうのはどうでもいい 実際にやってる人の言うことは違う
React Native開発のつらい点まとめ
https://mmiyauchi.com/?p=1526
大前提として「React Nativeは、Viewしか扱わないReactがベース」である
ことあるごとに、パッケージを追加していく開発スタイル
WebでのReactのライフサイクルメソッドがネイティブアプリにマッチしているとはいえない
よく使われる定番のパッケージすら安定していない・ハマる
気がついたらGithubのIssueを読んでいる。気がついたらソースの中身を読んでいる。気がついたら1?2年前のStack Overflowをじっくり読んでいる
デバッガの動作が不安定だし、重い
React Nativeで解決できない箇所は、React Nativeが吐き出したネイティヴ向けのコードをメンテナンスすれば良いと思っていたら、難易度高そうで諦めた
コンポーネント志向とか言いながら、オリジナルのコンポーネントの再利用が起きなくて、コンポーネントのメリットをあまり享受できた感じがしない
GUIでUIを編集できるツールがない・これというオンリーワンなIDEがない
アプリケーションのパフォーマンスは各端末上で動作するJavaScriptインタプリタの性能頼み
画面切り替えをすると、表示中コンポーネントがアンマウントされる。新しい画面が出現するとコンポーネントがマウントされる。
画面をアンマウントされなくて良く、バックグラウンドで動作するという選択肢はなく、画面の状態・処理状態を任意に保持・破棄することができない
画面間での情報の受け渡しに非常に弱く、基本的にはReduxなどの外部でstateを管理するシステムを使うことになる
プッシュ通知が公式では最新のv0.45でもiOSしかサポートされていない
総評: React Nativeでは、ネイティブアプリ開発に必要不可欠なものすら公式から提供されていない。
なので、色々とパッケージを盛りまくって、盛ったパッケージの英文資料を読みまくり、
JSXタグを打つのが開発の大半となってしまう。Androidについては気合いでなんとかする >>898
> Airbnbの数倍以上の規模があるFacebookアプリで使われてるからそういうのはどうでもいい
でもお前の会社Facebookよりも遥かに規模小さいじゃんｗ >>895
React Nativeはウェブで使うものじゃないぞ。
それはiOS/Android用だ。
ウェブで使うなら、React Native for Webを使わなければいけない
https://blog.nkzn.info/entry/2018/05/29/210030
> React Native for Webは、React NativeをWebに持ち込む試みです。
>
> ブラウザはGUIアプリケーションプラットフォームではない
> まず前提となっている思想として、 WebブラウザはGUIアプリケーションプラットフォームではない 、
> というものがあります。ブラウザは元々ドキュメントビューアであり、Webページで
> 情報を閲覧するためのソフトウェアであり、アプリケーションのランタイムではなかった、という立場です。
React Native for Web
https://github.com/necolas/react-native-web
↑これみてわかるか？ これは React Nativeの一部ではない ウェブ版があるのに、それをそのまま
アプリにしたって意味がない。
誰もやらないが正解 マルチプラットフォームはやっぱり、Cordova, Haxe に戻った方が良いかも このなかで一番美人なのって真ん中だよね？深キョンレベルだと思うのだが
ちなみに向かって右は目も鼻も整形してるって本人が公言してるけどそれ抜きにして誰が一番美人だと思う？
http://bigsta.net/media/1933567086757747003_3564907098 PWAとかフレームワークなんかで対応するもんじゃないよ
特にSWはアプリごとに調整しないといけないからね
キャッシュ廻りとか本当に難しい
最近色々FW出てるけどまだまだそれに任せっきりにできるレベルじゃない
後はインストールプロンプトとかライフサイクルの面倒もやっぱり
自前で見ないといけないからね そんなもんウェブサイトに必要なの？
どこに使うの？ PWAとRWDはレイヤが丸っきり違う概念だと思うが >>912
それはそうだけど、スマホ対応するには
スマホアプリにするしかないって思いこんでるやつがいるからさ
ウェブサイトをスマホ対応するには、単にRWDにするだけでいいって話
そうすりゃ>>907みたいなウェブサイトには無関係なことに時間を使わなくていい
ウェブサイトをReact化するとこんだけ大変なんだよっていう話さ なるほど。そういうことか。それなら納得だわ。
サイトを無理にウェブアプリ化しても何の意味もない アプリ向けだろ？
ウェブサイトはアプリではないと言ってる ウェブアプリはウェブサイトじゃないなんて
そんなオレオレ定義聞いたことないぞ >>918
お前みたいなやつがいるから馬鹿にされるんだよ ハノイの再帰の中に
ajax建てるプログラムを作ってるんだけど
関数はネストはちゃんとするけどコールバックが機能せず
終了してしまう。どうすればいい インストールできたらアプリっていうのは狭い考えで
Webアプリなどと言うときのアプリって機能性での分類だと思うけどな それはそうだね。だからウェブサイトとウェブアプリは機能が違う
機能が違うからウェブサイトはウェブアプリになりえないわけで
それをインストールさせる意味もない（ブラウザで見れば良い） >>921
たぶん、コールバックは、その外側の関数が終了してから呼ばれる
外側の関数A を実行
callback A を登録
再帰の関数B を実行
callback B を登録
再帰の関数C を実行
callback C を登録
関数C が終了
callback C が呼ばれる
関数B が終了
callback B が呼ばれる
関数A が終了
callback A が呼ばれる >>923
いや、一部かぶってると思うよ
ニュースサイトだったり、Qiitaみたいのだったり、
そのWebサイトで集中して色々見たり、頻繁に閲覧するニーズがあるもの、
言い換えると雑魚サイト以外はインストールさせる意味があると思うよ
インストールと言っても、実際はブックマークみたいなものだもの そのサイトを見れるブラウザコンポーネントのっけてるだけのアプリとかもあるしな >>926
作るのは勝手だが、お前、入れてる？
ただのウェブサイトをアプリにしただけのものを。
入れてないでしょ せやな。ユーザーが作ったデータをアップロードするとかだな。
普通のサイトはせいぜいお問い合わせフォームがあるぐらいやで
お問い合わせアプリでも作るか？ｗ >>931
でも実際、日本の大企業の公式アプリはそんな感じ
トヨタは車種の検索とお問い合わせフォームがあるだけ。
今はもう少しマシになったかも知れないけど >>932
典型的な「間違った使い方」だなｗ
だから誰もそんなアプリいれない。 >>928
入れてるよ
chromestatus.com とか
気になったときにブラウザ立ち上げてブックマークからってのは結構面倒だもの
デスクトップのようにブックマークバーが無いと体験だいぶ違うからね
やっぱりそうだね、「ちょくちょく気になる」サイトはホーム画面に並べる価値があるってことだろうね
地味にオフライン対応ってのにも助かったことがある オフライン対応って実はブラウザでも出来る事なんだけどね
認知度は低いか >>935
認知度云々は関係なくて
PWAにする効果としてブックマーク的な側面はいいとして
ただのブックマークとは違って上で話題になったSWが必須
≒オフライン対応必須って点も意義があることもあるんだよという体験話 で、ほとんどのサイトはオフライン対応とかする意味ない 検索でたまたま訪れただけのサイトとか
キャッシュされても困る
どうせ他のページなんて見ないのに
サイト全体をダウンロードとか無駄に通信量増えるだけ
格安SIMで月3GBに抑えてるって言うのにさ 全体なり部分なり精密な調整が効くのがSWの有用性だと思うんだけど…
なんでほとんどのサイトとやらに固執するのさ
誰も使えなんて言ってないのに 質問してよろしいでしょうか？
onclick属性に関数を設定したい時にその時に引数の中身を渡すにはどうしたらいいんでしょう？
以下例ですが、piyoがある要素を指している状態で
var hoge=1
piyo.onclick=function(){alert(hoge)}
hoge=2
とすると、クリック時には2が表示されてしまうのですが、1を表示させたい、つまり
2行目の実行時点での変数の内容をonclickの命令の中に埋め込んでしまいたいのですが
どうしたらいいのでしょうか… ↑すみません変な文章でした
×onclick属性に関数を設定したい時にその時に引数の中身を渡すにはどうしたらいいんでしょう？
○onclick属性に関数を設定したい時にその時の変数の中身を渡すにはどうしたらいいんでしょう？
です function f(foo)
{
alert(foo);
}
document.getElementsByTagName("html")[0].onclick=f(1);
動かんｗ
無名関数だと楽勝なんだけど、なんか難しいのう >>941
piyo.onclick=function(){var hoge=1; alert(hoge)}
var hoge=2 いまいちやりたいことをわかってないが
こういうことなんだろうか
var hoge = 1
piyo.onclick =(function(a){return function(){alert(a);}})(hoge);
hoge = 2 しかしこれ設計ミスではなかろうか
DOM、特にinputのvalueかなんかをもって気体のでは？ >>943
<span id="hoge1" class="hoge" data-hoge="1"></span>
<span id="hoge2" class="hoge" data-hoge="2"></span>
$('.hoge').on('click', function() {
alert($(this).data('hoge'));
});
もしくは
function f(event) {
alert(event.data.hoge);
}
$('#hoge1').on('click', {hoge: 1}, f);
$('#hoge2').on('click', {hoge: 2}, f); >>947
いやjQueryやと楽勝やけどさ〜
生js難しいねぇ。こんなんもかけないとは、トホホ もうjQueryでいいじゃん
どうせ生jsにしたって長くなるだけなんだから >>945の別バージョン
var hoge = 1;
var makeonclick = (v) => (() => { alert(v); });
piyo.onclick = makeonclick(hoge);
hoge = 2; 生のJS で書くと、保守コスト・人件費が、大幅に上がる
書いたコードの説明も必要だし、ちょっとした事でバグるし ボタンを押したら画面更新せずに特定のUAに変更するってjavascriptで出来る？ >>954
できる
<link href="~css">
を書き換えレバ別のcssを適用できる
が普通こんなことやらんよ >>956
だれも別のcssにするなんて言ってない
ちょっと頭悪い人消えてくれないかな。じゃま みなさんありがとうございます、説明不足でしたが
このルーチンはループの中で実行されるもので、ループの中でhogeの中身は予測不可能に変化するんです
だからhogeの中身が1だと決め打ちするようなやり方はだめでして
あくまでも実行時点でのhogeの中身をDOMに移して埋め込むことが必要です
これから１つずつ試してどれが良かったか検証してきます
ありがとうございます >>943
document.querySelector('html').onclick=_=>(_=>alert(_))(1) だからサンプルリストとしてはこう表現すればよかったですね
var hoge=prompt("入れてー")
piyo.onclick=function(){alert(hoge)}
hoge=2
ではいってきます というわけでやってきましたが>>945でいけました
似たようなことはやっていたのですが。
しかも動いたのは良いのですが未だにどうしてreturnしたり無名関数で二重にくるむと変数を渡せるのか仕組みが分かってません
理屈を説明していただけると有り難いです 理屈は見たまんま
コードをほぐして
１つずつステップを追っていけばいいというか
自分でそれができない人に説明はできない jsは古い仕様と新しい仕様がごっちゃになってるけど人気なんだよな jsは全部オブジェクトで何でもかんでも渡せるっての知っておかないとしんどいかも 人気というよりクライアントサイドだと他にほぼ選択肢がないというね 初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017 >>941
普通に先に待避させればいいんじゃね
var hoge=1
var foo = hoge
piyo.onclick=function(){alert(foo)}
hoge=2 electronと組み合わせるなら
vueとreactどっちがいいの お前がエレクトロンで何をしたいのかもわからんのに答えろとか何様だよ フロントとバックエンドを微妙にどっちもやったことあるんだけどさ
絶対フロントからやった方がいいと思うんだよね
バックエンドやる上で、HTMLのタグや属性が大事になってくるもん
バックを最初やって繋ぎを探すときになんとなくHTML読んでた バックエンドはviewやtemplateはいじりません うっそ、うちのとこはviewはバックもやるんだけど
てかフレームワークでviewの話出てくるし みんなのとこは設計やる？
他のスレ見てるとweb業界は設計書なんて作らないぜーwみたいな人多くて
うちの会社はDB定義と、画面仕様(変数とか何もない)と、流れだけ書いた資料作ってから実装なんだよね
だから自分はプログラミングの実績つんだら設計からやりたいって上司に相談中
戻しがありすぎて効率悪いと思うんだけどな
一流プログラマー()は設計書とかなくても作れるんだろうか 設計というか仕様書とフローね。これは必須
DB定義書は当然あるけど上記次第で決まる
でも覆されるのがこの業界
いかに先方の真の欲求を最初に聞き出せるかがSEの腕の見せどころ
先方の言ってること以上の本当の仕様を聞き出せないと泥沼になるぞ スマホの切り欠きってCSSとかで対応できるけど
フォルダブル端末のサイドに表示できるようになるとかそういう情報知ってる人居る？
PWAのとき限定でも良いんだけど折りたたみ機構とサイドを使ったアイディアがいくつかあって試したい Reduxわかんないんですが死んだ方がいいですか？ reduxはreactの複雑なstateとpropsを使いやすくしたものなのでわからないというほうがおかしい
むしろ簡単になる レス数が950を超えています。1000を超えると書き込みができなくなります。
