Photo by rawpixel on Unsplash

Rails + Trix + Stimulusで作るドキュメント管理ツール - 導入編

Kota Miyake
Ruffnote
Published in
8 min readOct 1, 2018

--

Railsの作者であるDHHがCTOを務めるBasecamp。

そこからはプロダクトから生まれたツールがいくつもあります。

PowTurbolinks、そして今回紹介するTrixStimulusもその中の1つです。

ということで、これからいくつかの記事に分けてRails + Trix + Stimulusを使って簡単なドキュメント管理ツールを作ってみたいと思います。

MVPで以下のようなゴールを設定しました。

  • ドキュメントを閲覧、作成、更新、削除できる
  • 編集履歴を管理できる
  • 編集前後で差分を表示できる

Initial commit

さっそく作り始めていきたいと思います。

$ rails new writer
$ cd writer
$ cp config/database.yml config/database.yml.sample
$ echo config/database.yml >> .gitignore
$ git add .
$ git commit -m "Initial commit"

これでプロジェクトの雛形ができました。

ドキュメントを閲覧、作成、更新、削除できる

まずは「ドキュメントを閲覧、作成、更新、削除できる」という要件から実装していきたいと思います。

シンプルなCRUD処理で良いのでscaffoldを使ってベースとなる部分を作ってしまいます。

$ rails g scaffold document name content:text

なにやら色々とファイルが生成されます。

まずはマイグレーションファイルを編集します。

diff --git a/db/migrate/20180928000459_create_documents.rb b/db/migrate/20180928000459_create_documents.rb
index bc9812b..0963def 100644
--- a/db/migrate/20180928000459_create_documents.rb
+++ b/db/migrate/20180928000459_create_documents.rb
@@ -1,7 +1,7 @@
class CreateDocuments < ActiveRecord::Migration[5.2]
def change
create_table :documents do |t|
- t.string :name
+ t.string :name, null: false
t.text :content

t.timestamps

ドキュメントの名前は必須にしたいので、null: falseオプションを追加しておきます。

ではマイグレーションを実行したいと思います。

$ rails db:migrate  
rails aborted!
ActiveRecord::NoDatabaseError: Unknown database 'writer_development'
/Users/kotamiyake/code/private/projects/writer/bin/rails:9:in `<top (required)>'
/Users/kotamiyake/code/private/projects/writer/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'
Caused by:
Mysql2::Error: Unknown database 'writer_development'
/Users/kotamiyake/code/private/projects/writer/bin/rails:9:in `<top (required)>'
/Users/kotamiyake/code/private/projects/writer/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

おっと、失敗してしまいました。

データベースを作成していませんでした。

気を取り直してデータベースを作成してからマイグレーションを実行します。

$ rails db:create && rails db:migrate
Created database 'writer_development'
Created database 'writer_test'
== 20180928000459 CreateDocuments: migrating ==================================
-- create_table(:documents)
-> 0.0236s
== 20180928000459 CreateDocuments: migrated (0.0237s) =========================

無事成功しました。

ここでサーバーを起動して確認してみましょう。

$ rails s

Yay! You’re on Rails!無事表示されました!

✔ドキュメントを閲覧、作成、更新、削除できる

システムテストを書こう

次のステップに進む前にRails 5.1から導入されたシステムテストを使ってテストを書いてみることにします。

と、思ったのですが、scaffoldで作成した場合にはシステムテストも合わせて生成されていました。

システムテストはtest/system以下にファイルを作成します。

せっかくなので、システムテストの中身を確認してみましょう。(一部抜粋

require "application_system_test_case"class DocumentsTest < ApplicationSystemTestCase
setup do
@document = documents(:one)
end
test "visiting the index" do
visit documents_url
assert_selector "h1", text: "Documents"
end

Railsのシステムテストにはcapybaraが使用されているので、普段からcapybaraを使っている人は違和感なく導入できるかと思います。

RSpecではfeatureスペックとして書いていたのですが、今後はシステムテストとして統一していくとRails Wayに乗った感じで良さそうです。

RSpec公式ブログでもRailsで用意されたシステムテストを利用していくことを推奨しているようです。

As such, we are recommending that users on Rails 5.1 prefer writing system specs over feature specs for full application integration testing.
http://rspec.info/blog/2017/10/rspec-3-7-has-been-released/

また上記の記事にはfeature specとsystem testの違いが説明されています。

貧弱な英語力でまとめると、

  1. feature specはRailsアプリとは別プロセスで動くため、Railsで用意されたデータのrollbackがうまく動かないため、database_cleanerなどのgemが必要だったが、system testでは必要ない。
  2. feature specはcapybaraのdriverにデフォルトでRack::Testを使っていたため、jsを使ったテストではdriverを変更するなど若干トリッキーな設定が必要だったが、system testではdriverにデフォルトでSeleniumを利用しており、トリッキーな設定がRailsに隠蔽されており、特別な設定をしなくてもそのままテストがかける。

ということのようです。(正確な内容は原文をお読みください…

記事が長くなりそうなので、残りの要件については次回以降の記事で書いていきたいと思います。

ここまでのコードは以下のリポジトリで確認できます。

https://github.com/kmiyake/writer

Railsの機能はどんどん進化していくので、しっかりキャッチアップしてどんどん活用していきましょう!

--

--