元スレ+ JavaScript の質問用スレッド vol.135 +

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

53 = :

朝鮮人みたいに揚げ足とる根性悪い奴がいるな

普段何の仕事してんの？
ニート？

54 = :

根性悪いやつが居るように見えるのは本人が根性悪いんだろうな

55 = :

朝◯人と悪口いってる時点で人の屑
ジャップのくせに

56 = :

「朝鮮人」は今や悪口ではないし
「JAP」は昔は米国新聞でも普通に使われてたただの略語というか日本の愛称だった
たかが三文字の言葉であれこれ思うのも馬鹿らしいよ

57 = :

ヴァーカ

58 = :

リアルで朝◯人なんて言ってみろよ
どう言うことになるか分かるか？

リアルで言えない差別用語をネットで
使って吠えてる糞野郎

59 = :

某氏のカメラの話思い出した

60 = :

>>58
意味分からん
中国人
フィリピン人
朝鮮人
普通に使うぞ

変な嫌悪感を持ってるのはそういう学校教育された中年世代だけだろ

61 = :

【研究】飲むだけで差別主義者が更生する「道徳ピル」
＞米国では、多くの学生が成績向上や適性試験をパスするために、リタリンを治療以外の目的で服用しているとの報告がある。

差別主義者は薬物でも服用させなければ駄目だな
市ぬかもしれないが生きてても仕方ない奴らだからどうでもいいわ

62 = :

>>60
韓国人　は入らないんか

63 :

知能が低いと複雑なことを考えられないから
極端な白黒思考になる
これが差別主義者

道徳ピル飲んで知能を上げるしかない
薬害で市んだら害虫が一匹消えたという事でそれはそれでおっけ

64 = :

>>50
言葉で説明してくれ

65 = :

DOMは仕様がコロコロ変わる
だからその違いを吸収するライブラリが必要になる

66 = :

逆だな
原則DOM標準は後方互換性を守る
JSのライブラリはバージョンアップで簡単に切り捨てる
ライブラリを使ってるとむしろ追従が大変になる

67 = :

自分の引き出しにあんまり実例なくてわからないんだけど
バージョンアップで切り捨てるって旧UAを？だったら旧バージョン使い続ければ良いのでは？

68 = :

uaって？無駄にコンテキストから推測させないでほしい。
あなたは数文字節約できるかもしれないけどこっちはいい迷惑。

69 = :

>>67
パフォーマンスや新機能のためにバージョンアップしたくても
再設計が必要なほどAPIが大きく変わってることが珍しくないということ
YouTubeのCr以外で遅い問題もPolymerがそうだからYouTubeが追従できないから

70 = :

crって？無駄にコンテキストから推測させないでほしい。
あなたは数文字節約できるかもしれないけどこっちはいい迷惑。

71 = :

>>66
> JSのライブラリはバージョンアップで簡単に切り捨てる
> ライブラリを使ってるとむしろ追従が大変になる

どのライブラリ？ AngularとかReactとかかな？
なんか更新頻度高いしね

その点jQueryは安定していていいよ。
そもそも追従するほどバージョン出てないしｗ

72 = :

>>69
それ、単にそのライブラリ・フレームワークの設計が杜撰ってことじゃ
その互換性の部分以外のとこも大丈夫なのか？となりそう

73 = :

angularって言うほどいいかな？
偉そうな事言うのは嫌なんだけど
vueやreactの方が絶対いい

74 = :

>>72
杜撰ってわけでなくJS界のトレンドなんだろうな
jQueryみたいに切り捨てられないと（それでも利用度からすれば比較的切り捨ててる方）
負の遺産化するし

75 = :

>>74
jQueryは負の遺産にはならんよ。
DOM操作を短く簡潔にするためだけのものだから
使わないならjQuery1行をそのまま数行に対応付けて書き直せる
冗長になりますよってだけで誰もやらないけどね

負の遺産っていうのはAngularやReactなどの
最近のフレームワーク。違う書き方にしようとしたら
全体に手を入れなければいけない

76 = :

フレームワークは離脱するには設計から構造からやり直さないといけない
jQueryのようなライブラリは設計構造はそのままで済む場合が少なくない（※）が使用部分が広範になりがちで書き直し量が多い
※例えばアニメーション関係をjQueryに頼っていると構造にも絡んでくる
独特な機能を提供するライブラリは関係部分だけ書き直せば済むといえなくもない

77 = :

フレームワークで作られるのは迷惑。
意識高い系の人がフレームワークで使って作ったサイトをサーバに乗せるのに凄い苦労した経験あり。

78 = :

jQueryで唯一評価されるのはSelectorsAPIの基礎になったってことだけ

79 = :

element.style="width:100px;background-color:green;";
でいけたんだけど、element.style.width="100px"みたいにプロパティと値をわけて書くのと何か違いはありますか

80 = :

パース速度？

81 = :

可読性がよくないぐらいでは
element.setStyle({
　"width": "100px",
　"background-color": "green",
});
とかがあればいいな
prototypeいじりたくないけど

82 = :

>>79-81に便乗質問なんだけど
・element.styleにはCSSStyleDeclaration オブジェクトが入ってる
・element.styleに直接CSS定義テキストを代入できる
・element.styleに直接CSS定義テキストを代入した直後でも
　element.styleにはCSSStyleDeclaration オブジェクトが入ってるし
　element.style.width を変更することもできる

CSS定義に変更があった場合変更内容を元にelement.styleを再設定してるという感じだと思うんだけど
こういう挙動はどう理解したらいい？

より具体的には、ブラウザの実装がそうなってるというだけなのか
それとも同じような挙動をユーザがjsコードで実現できるのか

83 = :

>>82
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Proxy

84 = :

>>81
Object.assign(element.style,{
　width: "100px",
　backgroundColor: "green",
})

>>82
内部Proxyだと理解したら良い

85 = :

>>78
SelectorsAPIなんてjQueryの劣化版だろｗ

単にNodeListを返すだけで、そのNodeListを扱う方法まで作らなかった
jQueryはNodeListみたいに単に要素の配列を返すのではなく
要素の配列を内包した、jQueyrオブジェクトを返すことで
要素の配列そのものをメソッドで操作できる

ここが重要な所なのに、SelectorsAPIはそれを理解せず
単に要素の配列を返しただけ

86 = :

jQueryはいつgetContextに対応してくれますか
あとマウス座標取得決定版みたいなのも欲しいです
$(event)みたいにできたらいいのにな

87 = :

>>83-84
thx
あるんだな・・・意義はわかんなくはないけど正直どうかと思うが・・・
あとでじっくり読んでみる

88 = :

>>86
getContextに対応するだけでいいの？
canvas自体に対応しないとあまりメリットなくない？

jQueryになれてるなら、D3.js を使うのが良いと思う
canvas操作をjQueryライクに書くことができる
俺も普段はjQueryを使うけど、canvasを操作したい場合はD3.jsを使うよ

こんなk何時
http://codezine.jp/article/detail/7459

> D3.jsのセレクタを用いて宣言的に記述すると、以下のように簡潔に記述することができます。
> d3.selectAll("p").style("color", "white");
> 　コードも、d3.selectAll("p")ですべてのp要素を取得、style("color", "white")で
> 文字色を白に設定、と直観的で分かりやすくなったのではないでしょうか。

89 = :

>>86
> $(event)みたいにできたらいいのにな

$(window).on('mousemove', function(event) {
　console.log(e.screenX);
　console.log(e.screenY);

　console.log(e.pageX);
　console.log(e.pageY);

　console.log(e.clientX);
　console.log(e.clientY);

　console.log(e.offsetX);
　console.log(e.offsetY);
});

91 = :

>>87
今だったらもしかしたらゲッターセッターになるのかもしれないけど
それらがJSに無かったころからCSSOMはあるしね
配列のlengthのようなものだよ

95 = :

変数に型は付けないよ。

97 = :

A → B → C → D
とasync関数が繋がってるのをイメージしてください
Aから始まりEが完了すれば順にC、Bと完了してAに戻ってくるイメージです

ここで、Dの段階でBからの流れをやりたいとします
しかし、Dの次にBを続けると、
それまでのB → Cの流れの中で消費されているメモリが残ってしまいます。

もうDや過去のCやBに戻らせる必要はありません。
しかし、Dを開放してB'を開始すると、Aまで完了してしまい、それはよろしくありません。

A → B → C → D
まで来たところで
A → B → C → D → B' → C' → D'
となるのはメモリリークしやすく、チェーンが非常に長くなると色々なバグも発生しやすく
デバッグのしやすさにも関わってくるので避けたいです

とはいえ
A → B → C → D -...> B' → C' → D'と切り離すと
Aで行っている初期化・完了・例外処理から外れていってしまうため問題です

理想的には、チェーンをA → B' → C' → D'
とつなぎ直したいのです
どうしたらよいでしょうか

98 = :

ただの再帰とちゃうの

99 = :

設計段階でみょうちきりんな動きの要求を加味しとけよ

100 = :

仕様としては、どの処理進行状態でもリセット、ぶつ切り行為が発生しうるという状況です
一応今はBで作業キューを持ってそれにCを追加する形にしていますが、
いかんせんコードがキレイではありませんし、僅かな仕様妥協が入ります

おそらくPromiseのラッパー的なとこから、根本的な非同期チェーン構造を
素朴なPromiseではなく１から考え直して別の物にすべきだと思うのですが
いいアイディアは無いでしょうか

全てのasync、async generator関数でCancelの概念と実装をしたら良いのでしょうか
全てのawait時にそれがCancelかどうかチェックして処理をするとか
それはそれで漏らせないコードが多くなりそうですし、処理が複雑になりそうです

一応今は各処理にセッションを渡すようにしていて、表に影響がある処理ではそのセッションが切れていたら何もしないことで、
特にイベント等から繋がる不要なチェーンが発動しても空回りさせることで影響がないようにしています
今はメモリの開放は時間経過やイベントをあえて見捨てたチェーンに伝わらせて
空回りを利用して自然と勝手にほぐれて、その後GCが回収してくれることに頼っています

しかし、今回は下手に空回りもさせたくないという状況です
コードを極力シンプルに保ちながらしっかりしていてかつ柔軟性も持った非同期処理構造を作るにはどうしたらよいでしょうか

例えば非同期でも、場合によっては完了を待たずに次に進みたいことってありますよね
例えば、Loadingを表示するとき
await View.fadeInLoadImage()
let file = await Network.fetchFiles( )
await View.fadeOutLoadImage()
とするとフェードイン、アウトの時間が無駄なので
View.fadeInLoadImage()
let file = await Network.fetchFiles( )
View.fadeOutLoadImage()
とすると思います。ですが、このフェードが動いているときに
コンテキストがリセットされると、色々懸念事項が生まれます
そういうのもスマートに扱える方法を知りたいです

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ

類似してるかもしれないスレッド

• + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
• + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
• + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
• + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
• + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
• + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
• + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
• + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
• + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
• + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
• + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
• + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
• + JavaScript の質問用スレッド vol.105 + (1001) - [97%] - 2013/5/20 4:45
• + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
• + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
• + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
• + JavaScript の質問用スレッド vol.117 + (1009) - [95%] - 2014/8/5 3:30