フロントエンドの「想定外」に対応する考え方とTipsいくつか
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純（後述）だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない！！ と思いました。 フロントエンドの想定外 ウェブサイト
webpack 4 の optimization.splitChunks の使い方、使い所 〜廃止された CommonsChunkPlugin から移行する〜 - Qiita
webpack 4 の optimization.splitChunks の使い方、使い所 〜廃止された CommonsChunkPlugin から移行する〜JavaScriptwebpack はじめに 先日リリースされたwebpack 4でCommonsChunkPluginは廃止されました（CommonsChunkPluginの解説はこちら）。 その代わりとした追加されたoptimization.splitChunksの基本的な使い方、使い所に関しての記事です。 optimization.splitChunksを利用すればサイトパフォーマンスの改善（詳細は後述）ができるため、利用する機会が多い設定（機能）です。 解説に利用しているコードの最終形態はGitHub上にあります。 hira777/webpack-split-chunks-example webpackを理解していることを前提
超高速な静的Webページを作ろう！ - Qiita
PageSpeed Insights 計測結果 モバイル/パソコン 共に100点 速度という点に絞ると信用できるものではないかもしれませんが、100点という数字は単純にうれしい:) それでは！以下が私のやったことです リクエスト数を極限まで減らす CSSはstyle属性やstyleタグで設定 複数箇所で使う場合はstyleタグに、要素固有のスタイルはstyle属性で設定してしまいましょう。 style属性で設定する場合はセレクタでの捜索が発生しないので、ごく僅かながら速くなると思います。 画像はbase64で埋め込む こことかでデータURIスキームに変換してhtmlに埋め込みます。 base64エンコードすると容量が1.3倍くらいに増加するため大きな画像には向かない方法ですが、小さなアイコン程度ならリクエスト数減らすほうが効果的な場面があります。 複数箇所に使う画像の場合はCSS変数でba
TypeScript+webpack+Hypernova on RailsでSSRするときの設定ファイル - Bit Journey's Tech Blog
「Roppongi.rb #3 で「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」という発表を行いました - Bit Journey's Tech Blog」あたりの話のなかで触れている、KibelaにおけるJSのビルド環境に関係する設定ファイルなどを公開します。 現在もこのときと基本的な構成は変わっておらず、すでに数ヶ月安定して運用できています。 環境 Rails v5.1 TypeScript v2.5 webpack v3.6 Hypernova*1 webpackerは不使用で、webpack-rails*2を使用 ディレクトリ構成 client/ - フロントエンド用TSコード（.ts, .tsx,.json） spec/javascripts/* - テスト用TSコード なおプロダクション用フロントエンドコードは 100% TypeScript です
APIサーバを立てるためのCORS設定決定版 - Qiita
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！ という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
