元スレ+ JavaScript の質問用スレッド vol.137 +
JavaScript覧 / PC版 /みんなの評価 :
151 = :
$.ajaxのget使うときにurlのパラメータを指定しますが
{"url":'ht略://sample.com/api.php',
"type":"GET",
data:{"hoge":2,"fuga":3}
}
とした場合403が返ってきます。でも、
{"url":'ht略://sample.com/api.php?hoge=2&fuga=3',"type":"GET"}
みたいに"url"に書いてやると問題なくなります
考えられる原因はなんでしょうか
152 = :
>>151
記述を間違えている
開発ツールのnetworkタブで見てみると良いかも
154 = :
$.ajax使わないで、$.get使えばいいのにっていつも思うんだが
なんでわざわざ冗長なのを使うんだ?
155 = :
Axios と言うのを、本でよく見る
156 = :
>>154
ajax()ならgetでもpostでも容易に切り替える事ができるって理由で使っていたな
要は実装が決まってない状態
この状態を悪いって言わないでくれよ、この状態になってるから仕方ないんだ
157 = :
getは取得でpostは送信だろ?
なんでどちらかが決まらないなんてことがあるんだ?
今はデータ取得してるけど
もしかしたらデータ送信するかもしれない
とかか?なんでそんなのがあるんだ?
161 = :
>>157
データを取得するけど指定したパラメタに応じた副作用があるAPIはどっちにしたらいいんだ?
162 = :
>157
getは取得→いやそもそもその取得するためのデータを送信してるだろ
postは送信→いやその後取得するだろ
検索結果、登録情報の更新、など、決めないと難しいと思う
163 = :
1970年1月1日9時00分からの任意の経過秒数から
年月日と曜日を求めるにはどうすればいいんですか?
例えば 6300000000 secだったら西暦何年の何月何日何曜日かというようにです
165 = :
Date
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date
1970年01月01日 00:00:00 UTC (Unix エポック) からのミリ秒数を表す整数値です
(ただし、多くの UNIX タイムスタンプ関数は、秒単位でカウントすることを考慮してください)。
なお、閏秒を無視します
その、+9時間は、エポックを日本時間で表示しただけ。
内部的には、UTC で管理していて、表示する際、ローカルタイムに変換しているだけ
166 = :
>>162
> getは取得→いやそもそもその取得するためのデータを送信してるだろ
> postは送信→いやその後取得するだろ
それは屁理屈
167 = :
// 1970年01月01日 00:00:00 UTC (Unix エポック)
var dt = new Date( 1970, 0, 1, 0, 0, 0 );
console.log ( dt );
// 1日後
dt.setSeconds( dt.getSeconds() + 86400 );
console.log ( dt );
日付を扱うなら、moment.js が便利らしい
171 = :
splice()って取り除いたのを返すのかい?
174 = :
>>171
Array.prototype.splice()
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/splice
「javascript splice」で検索!
176 :
170です
165さん172さん、ありがとうございます。
しかしよく解りません。そのコードを、どこに挿入すればよいのでしょうか・・・
179 = :
キモイんでカッコの中にスペース入れるのやめてください
180 = :
関数呼び出しの後にスペース入れるのもやめてください
181 = :
昔Cのコードでよく見かけたなぁ
183 = :
ブラウザのコンソールで書いては消して試すのに便利だよvar
184 = :
ブラウザのコンソールでいちいちvarなんて書いてんの?
使い捨てるのになんでそんな面倒なことしてんの?
185 = :
オレ関数スコープがピッタリなところはvar使ってるわ。ブロックスコープ欲しいときは基本const、どうしてもミューテートしたい時やっとlet。letが一番使わない。
187 = :
不自由が好きな人も多いんだなあ
188 = :
効率的でもない、可読性や保守性が高いわけでもない、何のメリットもないこだわり
189 = :
なんか打つのめんどくてlet使うことが多い……
あとでconstに置換
あほか俺
190 = :
letのままでいいじゃん
191 = :
もしbabelでes5に変換してるんだったら関数スコープできてるとこはvarのままのほうがいいんじゃないかな。
変換後のコード量が意味もなく増える。
192 = :
>>178
☓ `${ dt.getFullYear( ) }年${ dt.getMonth( ) + 1 }月${ dt.getDate( ) }日`
○ dt.toLocaleDateString('ja',{year:'numeric',month:'long',day:'numeric'})
193 = :
>>191
babelはconstもletもvarに変換されるんだが?
194 = :
195 = :
>>194
えとさぁ、変換後のコードは増えないって意味なのわからない?
196 = :
>>195
あのさぁ…
197 = :
変換してからレスしようね
ほんとくだらない
198 = :
そもそもvarもletもよっぽど使わないでしょ
変数なんてなるべく変更しないものであるべきで、それならconst使うわけだし
変更しない変数にlet?
後から他人が読むこと考えろとしか
199 = :
>変数なんてなるべく変更しないものであるべき
そうなのか???
初めて聞いたぞ
200 = :
全部letでかまわんよ
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について