JSONとJSONPの違いって?その1

こんばんは、有村です。
気温の変化で、日々の服装に困る。

で、今日のテーマはJSONとJSONPの違いって?です!

Ajaxとか、フロントエンドならJSONを日常的に使いますね。
でも私、JSONPって、実は使ったことがなかったんです。使っても無意識のコピペくらい。
そういえば、「適当にJSONP使ったら殴る」って言われたこともありましたね…(遠い目)

なので、なんかよく分からないけどJSONPは危険なやつらしいってことと、他ドメインとのやりとり以外では使わないんだなってくらいしか理解していませんでした。
けど、なんでJSONPが危険なの?と改めて聞かれて答えられなかった&ついに使う機会に遭遇してしまったので、
少しづつ紐解いていこうと思いました。

まずは、JSONがなんの略か、から。
JavaScript Object Notation
notationは、特定の記号体系を持つ表記法のこと。なるほど。JavaScriptのオブジェクトの表記法、みたいな感じでしょうか。

MDNを見ると、

JavaScript の構文に基づいていますが、JavaScript とは異なります。

と書いてあります。あくまで別物ということですね。

で、先述のようにAjaxでJSONを読み込んで、それを基にDOMを操作したり(例えば「もっと見る」機能とか)すると思うんですが、
なぜJSONは別ドメインのものを使えないのでしょうか?
そこがクリアできれば、JSONPって要らないはずなのに。

理由は、ブラウザには同一生成元ポリシーというものがあって、自分(つまり表示中のページ)を生成したドメイン以外とは通信ができないようになっているから、らしい。
ええ…でもCSSとかJSとか、外部で読めるやん…と思ったのですが、ドンピシャで「XMLHttpRequest」が禁止されています。

Ajaxを使ってJSONデータ読み込むとき、XMLHttpRequestって使いますよね…つまり……
別ドメインのJSONを使えないのは、同一生成元ポリシーに引っかかるからなんだ!
なるほど…少しJSONちゃんのこと分かってきましたよ!

そしたら次に気になるのは、「JSONPを使えば、どうして他ドメインのJSONを使えるの?」ということなのですが…

まずはJSONをちょっと理解したところで、明日以降の続きに回したいと思います!力尽きた。

それでは、きょうはこのへんで。

ボタン作成で失敗したこと

こんばんは、有村です。
新年度を迎えても、実装でうんうん唸ってます。いつになったら立派になれるんだろうか。

さて、今日は備忘録としてボタン作成で失敗したことを残しておきたいと思いまーす!

何に失敗したかというと、ボタンに当てるCSSの選択と、HTML側の構造です。
(全然まだ最適解だとは思ってないのですが)

簡単に要所だけ書きますが、私こんな感じのソースを書いてました。

やりたかったのは、ボタンの中身を天地中央にするということ。
最初はline-heigetとpaddingを使っていたのですが、font-sizeとの兼ね合いもあったりとかで、「それだと高さを意識してボタン作るのが若干面倒だなぁ…」と思い、上のような形に作り変えました。

flexだとalign-itemsがあるじゃないですか。
そりゃ使うじゃないですか。
そしたらですよ。
実機(iPhone)で見たら崩れてた。

具体的にどう崩れていたかというと、ボタンの文言が思いっきり左に寄ってました。
普段はchromeのエミュレータで実装しているので、全く気付かなかったんですよね…。

なんでー!?って調べてみたら、どうやらブラウザのデフォルトスタイルとdisplay: flex;が干渉し合っており、flexのほうが競り負けているようだと知りました…。
いやらしいのがchromeは問題なく見れるということ。まだ見れてないですけど、IE11も大丈夫らしい。Edgeはダメだとかなんとか。

そこで有村は色々考えました。

1. かつてのpadding方式に戻す。
paddingを駆使して高さを設定するのはやはり面倒では?
高さを設定したいなら素直にheigetを使うべきじゃないか?
よって却下。

2. ボタンってもともと天地中央だから何もしなくてよくない?
わざわざflexを使った理由は、それがbuttonだけではなく、aタグなど他の要素でも使用されるため。
よって、buttonのデフォルトスタイルに頼ればいいや〜が使えない。
これも却下。

3. buttonがダメならinputは?
そもそも試していないけども、inputは空要素なのでbeforeやafterが使えなかったり、小回りが効かない時点で却下。

4. HTMLとCSSを書き換える

みたいな。要は間にspanをかませる。
デメリットとしては、本来ひとつで完結するはずなのに、buttonとspan(場合によってはaとspanなども)のようにHTML側の記述が増えてしまうということ…
けれども、現時点ではこれ以上の策は無さそうだし、「ボタンを配置する時はspanもセットで」というルールがあればいい話なのかなと思ったので、この案を採用しました。

form系はどうも痒いところに手が届かない感がありますね…
いつか「そんな日もあったね〜www」という時代が来ればいいのですが。
ひとまず締めとしては、Appleさん早くなんとかして!!!!

それでは、きょうはこのへんで。

迷いながらボタンを作っている。

こんばんは、有村です。
お花見、歓迎会、懇親会……コミュ障には辛い季節がやってきましたね!

さて今日のテーマは、迷いながらボタンを作っているです。
もちろんボタンってウェブサイトのボタンですよ。有村はフロントエンドエンジニアですよ。

で、ボタンなんですけど…何に迷っているかというと、ボタンをどう設計すればいいの?ということ。

私がまずやったこととしては、

  • それぞれのボタンの共通部位を見つける
  • ボタンのデザインと役割の紐付けをする

でした。
たとえば、「先に進む」や「戻る」的なボタンがあったとして…

  • 共通部位 … 角っこが丸い。font-weightがbold。テキストは天地中央。
  • 先に進む系は背景とボーダーが赤、テキストが白。戻る系は背景が白、ボーダーとテキストが灰色。

みたいな感じ。

そこでボタンを設計しようと思ったところ、先輩に強調されたのが、ボタン自身に具体的な幅を持たせるなということ。
私はなんでだろうと思ったのですが、よく分からないなりにアドバイスに従い、こんな感じのextendとmixinとclassを作りました。

なんかいい感じじゃないですか!?
と思っていた時期が私にもありました。

Aページ「ここのbtn_nextは幅100px、高さ20px、font-sizeは13pxやで〜」
Bページ「ここのbtn_backは幅100%、高さ40px、font-sizeは15pxやで〜」
Cページ「ここはbtn_nextとbtn_backは横並びでどっちも幅を均等に、2つの間にはmarginを15px、高さは30px、font-sizeは15pxにするで〜」

ありますね!あると思います!!!!
つまり何が起きたかと言うと、
ページ(というか配置場所)によって、幅や高さやfont-sizeが違う。
うわぁどうしよう!!!!

んん…まぁできないこともない…でもなんだろう、このオーバーライドっぷりは。
最初のうちはこれでもなんとかなったんですけど、たとえば「入力フォーム系に配置するボタンは常にサイズが一定」とか、別のルールとバッティングした時に、収集がつかなくなったんですよね…。

そこで、一度立ち止まって考え直すことにしました。

絶対に変わらないもの = extend
角っこが丸い。font-weightがbold。テキストは天地中央。

それぞれのボタンとして独自のもの = mixin
ボーダー色、背景色、テキスト色

場所によって変わるもの = ボタン自身は具体的な数値を持たない
幅、高さ、font-size

これをソースに起こしてみると…

からの、

からの、

のように、ボタンの大きさがどのようにあるべきかを別のclassに委ねると、変なバッティングも起きなくなる…!
更に、form_btnはサイズ指定しか持っていないので、btn_backやbtn_next以外のボタンが来ても対応できる…!

また、親にサイズ感を委ねるという意味ではカスケードでもいけると思います。

まだ悩みに悩んでいるのですが、今のところたどり着いたのはこんな感じです。
何が正解かは分からないけど…

「あーこれやっぱり違う!」ってなったら、また記事にしようと思います。

それでは、今日はこのへんで。