Rails API + React でマッチングアプリを作ってみた - Qiita
概要 タイトル通り。バックエンドにRails（API）、フロントエンドにReactを採用したマッチングアプリ的なものを作ってみたのでアウトプットしておきます。 完成イメージ 割とそれっぽい雰囲気になってます。 使用技術 バックエンド Ruby3 Rails6（APIモード） MySQL8 Docker フロントエンド React TypeScript Material-UI 今回はバックエンドのみDockerで環境構築していきます。 実装の流れ だいぶ長旅になるので、これからどういった流れで作業を進めていくのかザックリ整理しておきます。 環境構築 Rails（$ rails new） React（$ create react-app） 認証機能を作成 gem「devise_token_auth」などを使用 マッチング機能を作成 中間テーブルなどを活用 バックエンドとフロントエンドを分離して
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
フロントエンドの消失 - または戦争が激しくなる話
React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド（とは？）の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域を食い合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHP や Rails の領分を侵そうとし
レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが
マネーフォワードクラウド経費でのフロントエンドの取り組み / moneyforward-expense-frontend
マネーフォワード Pay for Businessのフロントエンド / Money Forward Pay for Business Frontend
JSフレームワーク事情2020年始め｜erukiti
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS（Angular系の1.x系）の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
ゼロから始める TypeScript対応 Reactボイラープレート入門（前編） – FiNC Tech Blog – Medium
はじめまして。7月から業務委託として、FiNCのサーバーサイドエンジニアを担当している@yhirano55です。最近、来年3月に開催予定のRails Developers Meetup 2019の準備を始めました（次回は3トラック同時で進行する予定です）。 本記事では、Railsエンジニア向けに npm initから始める、TypeScript対応の Reactボイラープレートの作り方を紹介します。チームや組織で共通するボイラープレートがあると、SPA（Single Page Application）を量産する際に生産性が爆速になるのですが、ちょうど最近、Reactボイラープレートを作る機会を得まして、その過程で得られた試行錯誤を記事としてまとめてみました。 モチベーション Ruby on Railsを通してフロントエンドの実装をしていると、各種設定は、webpackerを使って簡単（暗黙
非SPAなサービスにReactを導入する - クックパッド開発者ブログ
投稿開発部の外村（@hokaccha）です。今回はReactについてのお話です。 ReactとSPA 最近JavaScriptやそれを取り巻くフレームワークなどの話題では、サーバ側はAPIのみを提供し、View(HTML)は全てJavaScriptで描画するような、いわゆるシングルページアプリケーション（以下SPA）についてよく語られます。 一方で、SPAを構築するにはコストがかかることも事実で、特にフロントエンドエンジニアが多くない環境では、従来通りサーバーサイドでViewを書きつつ動的な部分だけJavaScriptで処理するというアーキテクチャのほうが現実的な場合も往々にしてあります。 今回はこのような、サーバー側でHTMLを生成し、一部の動的な部分だけをReactで書くためのTipsを紹介します。 なお、基本的にサーバーサイドはRails前提ですが、RailsにおけるReactの開発
ActionCable + Reactでチャットをつくってテストをして、と一通りやってみたのでメモった。 - Qiita
まだ比較的に新しい機能なのでぐぐりんぐが効果を発揮せず、結果として、ちゃんとドキュメントやコードを読むことによる学びや、床板を踏みぬくなどがあったのでまとめます。 ActionCableの機能紹介といったものではなく、こうしたかったからこの機能を使った、使えなかった、こうしたら具合が良かった、という備忘録となっています。 書きながらコードも増えていったので長いです。 どのようなチャット マーマーチャットを覚えてる人はいますか？というか、まだあったりするんですかね。 ふきだし位置を自由に決められるチャットで、16年ぐらい前、チャットにはまっていた時期に利用していたのを思い出しながら、似た感じのをつくりました。 たしかJavaアプレットで動いていて、あれってWebSocketじゃないのかなーとフンワリ思い出したのがつながりみたいなものです。 バージョン Rails 5.0.0.rc1 よって今
Reactを導入したいRailsエンジニアの覚書き - 破いて捨てたノート
各フレームワークの特徴（つらみ）を整理 only jQuery Viewが状態を持ってしまう拡張やテストがしづらい DOMを指定してViewの更新処理を書くのはつらい Backbone.js Viewの更新処理を手動で書かないといけないのはつらい ModelとView間のイベント管理が煩雑になる イベント地獄になりがち 2 Way Data bindingを使ったフレームワーク（AngularJS、Vue.js、Ember.jsなど） コンポーネント毎に状態を持つとつらい 大規模になってくると状態を管理するのが難しくなる 単一方向データバインディング: データに対して、ビューの状態が必ず一意に決まる 双方向データバインディング: データに対して、ビューの状態が一意に決まるとは限らない refs: Introduction To React 今話題のReact.jsはどのようなWebアプリケ
Rails + React + ES6 のためのアセット環境構築 - 破いて捨てたノート
結論 Sprocketsの動作を維持しつつ、npmやgulpなどのモダンなパワーも取り入れた、いいとこどりな環境を構築してみた。 やりたいこと SEOのため、Reactでserver-side renderingをしたい JSコードをES6で記述したい 既存のCoffeeScriptのコードも共存させたい（後ほど書き換える予定） npmやgulpといったモダンな環境でアセット管理をしたい browserifyを使いたい Sprocketsが実現している機能は維持したい そもそもSprocketsは何をしているか 周知のことでしょうが念のためおさらい。 ファイル毎の依存関係の管理 application.jsなどのマニュフェストファイルがやってること altJSのコンパイル アセットのminify アセットの連結 アセットファイル名にMD5フィンガープリントを挿入 Sprocketsの問題点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
神速 on Twitter: "Rails + React.js はかなり難しいので、個人的には Rails + turbolinks + stimulus でできる程度の UI に仕様を抑えるくらいがコスパ良い構成じゃないかなと思っている。"
http://post.simplie.jp/posts/27