elmでSPAをわかってしまおう - Qiita
elmコミュニティの方々からSPAのベストプラクティスの提案・ご指摘を受けたので、時間が空いたタイミングで大きく更新をしようと思います。改めて思い直すことで結論などが変わると思われますので少々お待ち下さい (6/10現在) こちらは、elmによるSPA手法を解説していく記事になります。が、以下の記事をまだ読んでいない方は必ず目を通してください。 あなたはelmでSPAをわかってしまいたいのか？ ※ 本記事はelmのコードの読み書きにほぼ不自由が無い中級者向けの内容になります。それぐらい、ちゃんとしたSPAの難易度は高いです(私自身もわからないことが多いです。間違いがあれば指摘よろしくお願いします)。ただし、elmに限らず どんなフレームワーク・言語を利用していても役立つ情報かと思われます。 仕様 SPAを説明するにあたって、簡易的な宿泊施設の予約サイト(デモ)を作っていこうと思います。リポ
サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ - mottox2 blog
aircloset社で行われたWeb界隈LT会で話した「サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ」です。 > 静的サイトと動的サイト静的サイトと動的サイト > 静的サイト静的サイト 早くて、落ちないし、セキュリティで心配することも少ないけど、自由度低いよね。 > 動的サイト動的サイト 運用面倒。スケーラビリティ的に不利 攻撃される。 速度的に不利。 > 静的サイトジェネレータ静的サイトジェネレータ 動的に静的サイトを生成するジェネレータ 基本的にGitHubのpushと連動してビルドするような感じ > 時代は変わっている時代は変わっている monolithic services => micro services FTP => GitHub中心の開発環境の変化 PC => スマホシフト > GitHubを中心とした開発者の環境の変化GitHubを中心とした開発者の
SPA フルリニューアル計画における技術選定や設計思想（2019年2月版） - 30歳からのプログラミング
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
静的サイトを公開するならどこがいいの？ #技術書典 - Crieit
静的サイト（PHPやRubyなどのサーバープログラムを走らせない環境でのWebサイト）でSPAを公開するにあたって、運用・配信（ホスティング）するならどこがいいかと最近聞かれまして、その際の回答を技術書典の宣伝も兼ねてブログにしたためます。 今回は次の４つで比較しています。 GitHub Pages Firebase Hosting GitLab Pages Netlify 上記４つはどれも独自ドメインの設定とSSL対応が無料で行うことが出来ます。 ※比較的初心者に向けて書いている前提です。 AWS S3やGCP等の利用は初心者がいきなり設定を行うには項目が多いため除外しています。 レンタルサーバーも基本料金が発生し、スケール・管理し辛いため今回は除外しています。 また、少し機能について説明が必要な部分があるので、先に説明を書きます。 Rewrite設定について 静的サイト化したSPAを公
CSSレスポンシブデザインをSPAで使うと破滅する - 橋本商会
レスポンシブデザインは あくまで見た目の調整、表示・非表示のコントロールなので 下手に使うと、デバイス毎にインタラクションが違うUIのstateが無茶苦茶複雑になっていく コンポーネントという概念が無かった時代の設計を、SPAに持ってくるのはおかしい 画面サイズ毎にCSSで手軽にを切り替える、というのなら良い しかし、画面サイズ毎にインタラクションが違う部品が出てくると設計が破綻する 画面サイズ毎のがごちゃ混ぜになる コードが追えなくなり、バグの温床になる では、どうするか？ 素直に画面サイズ毎、デバイス毎、あるいはインタラクション毎のReactコンポーネントを書けばいい 使いまわせる部品は、コンポーネントとして切り出して再利用する 歴史を紐解く 2011年頃、レスポンシブデザインが生まれた 当時のwebにはコンポーネントが存在しなかった 単体で複雑な状態遷移をするインタラクティブなパーツ
SPAにおけるCSSについて、ひとつの解（追記あり） - エンジニアをリングする
SPAにおけるCSSのありかたについてずっと悩んでたけど昨日今日で一筋の光明が見えた— よしこ (@yoshiko_pg) 2017年4月7日 この話を簡単にまとめておこうと思います。 結論を先に書くと「今のところtemplate literal内にCSSを記述する形式のCSS in JSがいい感じ。Reactならstyled-componetnsが良かった」という感じです。 悩んでいたこと コンポーネント指向でSPAを作っていく上で、CSS（というかスタイリング）はどう書いていったらいいんだろう？ということに結構悩んでいました。 HTMLとJSがコンポーネントとしてまとまっていく中でCSSだけは今まで通り別物として扱い、BEMなどでグローバルスコープと戦うのか？はたまたCSSの枠をはみ出てJSコンポーネントの粒度に合わせたコンポーネント化をするのか？ 加えて、見た目も挙動も複雑なアプリケ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
