I'm guessing that since newly scaffolded Rails apps use webpacker, adding a gem like react rails would be an anti-pattern. that said, is there a canonical way to enable ssr on a rails app with react or would I need to run node as well for this?
I recently went through trying the 3 popular solutions:
Rails + Webpacker
Rails + Webpacker + react_on_rails
Rails + Webpacker + react-rails
react_on_rails opinion... It doesn't use integration tests that can use RSpec (Capybara) to combine both React + Rails environments. Both webpack and rails server are running via the foreman gem, which means you'd have to add another complex configuration to have RSpec integration tests that traverse both. There is also way too many settings that I was already configuring myself (Docker, Heroku, to name a couple...). The commit history the past year is also mostly doc changes (looking now this past couple weeks there has been some activity, though). Also it promotes a "Pro" edition, which kinda turned me off tbh.
react-rails is much more light-weight and was just easier to get working. The team is the official React team (reactjs.org). It "just worked" for me.
If you need a starting point, I'd recommend checking out this Rails starter kit that is built as a Rails + React setup:
https://github.com/patrickclery/dry-rails-react
Particularly these files:
babel.config.js
app/javascript/packs/application.js
app/javascript/packs/server_rendering.js
package.json
config/webpacker.yml
The gems are just another option, wondering why you see this gem in rails as an anti-pattern as there is a section in the react-rails gem documentation specific to webpacker. It clearly describes how to use the react-rails gem with Webpacker.
Here's another pretty up-to-date resource, which provides examples for
Webpacker
react-rails
react_on_rails
For webpacker it says:
All files in the new app/javascript/packs directory are compiled by Webpack.
For react-rails it says:
react-rails is the official React community gem for integrating React with Rails. The main benefit of using this gem is the react_component helper method which makes it easy to pass Rails data to components.
react-rails also gives you the option to continue using the default Rails asset pipeline to serve your React code, instead of using webpacker
For the third option react_on_rails it says:
The other most popular third-party gem for integrating React into Rails is the react_on_rails gem created by ShakaCode.
Similar to the react-rails gem, now that Rails already provides an easy way to use React via webpacker, you have to see if the stated benefits of the react_on_rails gem apply to your situation.
Related
sorry if this questions are too simple. Just started to learn Ruby on Rails and Spree ecommerce.
Successfully installed the demo store according the the instructions here: https://github.com/spree/spree , however, I don't quite understand how the source codes at the Github are linked to the sources codes on the Ruby on Rails spree ecommerce store. The directories are pretty different from each other. For example, spree source codes have "/API", "/backend", "/core", etc... while the ruby on rails spree ecommerce store has "/app", "/bin", "/config", etc...
I know the ruby on rails auto generates some codes. But how the two correlated with each other? Say, some codes at Spree ecommerce are updated, what to do to update the Spree store?
thank you very much!
You should read more about how Gem, Bundler and Engine works.
The Spree framework is a gem that works as an engine with each part(API, backend, frontend, core) separated in their own directories like a separated gem, just for better organization. Used to be all inside the Spree gem back in the day.
Your Rails app, the one with the 'app/', 'bin/' and 'config/' directories, is the true application, when you install/add Spree in your app it will be mounted alongside with your Rails app and will provide all the e-commerce platform.
In short when your add a gem into your Gemfile, the gem will be downloaded to your local system in the bundle install part. Rails will load the files from the gems listed on your Gemfile and everything will be good and accessible, automagically for you.
To update the gem spree you would have to use the bundle update spree command and the bundler will take care of updating the files.
To customize your Spree code, you can start to learn how in their guide.
What is the difference between Gem package, plugin, and Engine in Ruby on Rails?
I think we use the plugin before Rails3.2 and after rails3.2 is released we are using the gem package as a plugin but how can we use the engine in ROR?
Plugins as you knew them from Rails 2 (i.e. plugins under the vendor/plugins folder) were deprecated for Rails 3.2; support for it was completely removed in Rails 4. Now, there's a concept of a "gamified plugin" where the plugins are essentially built as gems and can be shared across different Rails applications.
But to answer your question about gems vs plugins, check out this Stackoverflow answer. Long story short, plugins from the Rails 2 universe is an extension of the rails application, whereas a gem is a packaged ruby application.
As for Rails engines, I've found this to be a pretty easy and intuitive definition of a Rails engine:
Rails Engines is basically a whole Rails app that lives in the container of another one. Put another way, as the docs note: an app itself is basically just an engine at the root level. Over the years, we’ve seen sen engines as parts of gems such as devise or rails_admin. These examples show the power of engines by providing a large set of relatively self-contained functionality “mounted” into an app.
And since both rails engines and plugins are types of ruby applications, they can all technically be packaged and used as a gem (usually).
There are no more plugins since Rails 4. Rails 4.0 release notes:
Rails::Plugin has gone. Instead of adding plugins to vendor/plugins
use gems or bundlers with path or git dependencies.
Any engine can be contained in a gem. Gem is just an alias to a 'library'.
Best way to see what their difference is is by generating three of them and looking through their directory structure:
bundle gem a_gem, used for non-rails-specific functionality.
rails plugin new b_railtie, used for rails extensions that don't require a full application-like setup. but, since it's still a rails-specific setup (you get your Rails dummy app in /test eg), you are probably going to use railtie in it. railtie is a class that inherits from Rails::Railtie, and gives you the comfortable DSL to hook up your code into Rails. eg, if you want some action performed :before some Rails app initialization step, you can use initializer Railtie class_method. Paperclip
rails plugin new c_engine --full, use for rails extensions that will be full-fledged app themselves, mounted into your app. will give you /app dir and Engine subclass besides basic non---full setup.
rails plugin new c_engine --mountable, same as --full, but will create namespaces, ready to be mounted into your app engine. Spree
And here is a pretty good link: http://hawkins.io/2012/03/defining_plugins_gems_railties_and_engines.
Engines are very related to plugins. Engines can be plugins and plugins can be engines. All of them can be created using rails plugin generator with 2 different options --full or --mountable.
I think the main difference here is between Engines and Gems.
Gems is just a bit of code providing a set of functionalities to anyone who integrates it into its code.
It contains:
Gemspec
Lib folder
Can be packaged and pushed to RubyGems servers
Engines are actually gems. All engines can be gems (if packaged) but not all gems are engines.
We can say it with a different word, Engines is a Ruby on Rails feature, that can contain Rails-specific entities: models, controllers, views, and migrations.
It needs to be integrated inside Rails application and can't run on its own.
Very good and quick read Artricle
When i tried to migrate my project from rails 3.0.6 to rails 3.2.rc2.
I found a lot of changes.one change seems to be node.js as javascript runtime.
whats the advantages on having node.js on it.By having node.js.
is it possible to migrate the rails lower version to the latest one
Rails 3.1 (and later) uses javascript runtime to compile CoffeeScript assets to javascript. You don't have to have node.js, there are other supported javascript runtimes.
This may be a very lame question, but still I am confused when should I use a gem and when should I should use a plugin in my project.
What's the basic difference between them?
The basic difference is a gem is something that needs to be installed on the system running your Rails application, whereas a plugin is deployed along with your application. More specifically, plugins live in vendor/plugins whereas gems need to be install using rake gem install gem_name.
As for when to use each, gems tend to be easier to keep up to date, but more specifically, some gems use native C code and are compiled specifically for a given operating system (such as Nokogiri). These need to be installed as gems as they will not work when moved to another system. Whereas some things like acts_as_commentable use straight ruby code and can be moved from system to system.
From RailsGuides:
A Rails plugin is either an extension or a modification of the core framework.
From Rubygems.org:
A gem is a packaged Ruby application or library.
So, the biggest difference between the 2 is that Rails plugins are specifically made for use within Ruby on Rails applications, whereas gems aren't.
For example, let's look at Geokit.
The gem (geokit-gem) provides the fundamental location-based operations.
The Rails plugin (geokit-rails) mixes location finders into ActiveRecord.
Here you can see that the gem provides the core of Geokit. This gem can be used anywhere, not just a Rails app. The plugin provides additional features for those who are using geokit within a Rails app. In this case, using the plugin as well as the gem is optional.
When you install a plugin in a project it can be used only in the respective project. But if u install a gem, it can be used by every project. This is the main difference of Gem & Plugins.
Gems are distributed by rubygems, which is the official ruby library package manager. Plugins is a (probably hacky) way for rails plugins. I recommend you using gems whenever possible, due to dependency resolution. Rails3 ecurages that by packing with Bundler.
I use gems whenever a gem works as I wanted to and plugins when I want to do a custom change for a specific rails application and not affect all of my system.
I am facing some problem with rails gem when deploying to a differet machine.It requires some extra work on installing gem.Which is most suitable for a rails project.Plugin or Gem.
For Some gems there is no corresponding plugins found.
I am searching for advantages of using plugin over gems and vice versa.
You can unpack gems to your Rails application, which will make sure that they are deployed together with your application:
rake gems:unpack:dependencies
Now you no longer have to install the gems on the server you deploy to. This already takes care of most of the deployment issues. Most others are solved by Bundler, which will be included with Rails 3.
If you can, use gems over plugins. Gems are generally easier to manage, because their versioning is superior to plugins. For public Rails extensions, I see no reason to use plugins instead of gems, but some authors only offer one of the two. In that case you have no choice.
I usually always use a plugin if it is available as it gets frozen into the project, meaning there are no issues when the project is deployed. You can freeze gems into a project but if they require a native build it causes more hassle than it's worth from my experience.
My understanding is gems are easier to upgrade than plugins.
You should also look into the rails 3 bundler which is used to handle these deployment issues.
For me, plugins are preferred. I've run into many a situation where I'll have an improperly configured environment.rb and gems won't have versions assigned to them. Then the server admin does a:
sudo gem update
And now my rspec tests won't run because the update installed test-unit 1.2.2 and my specific setup needs 1.0.1 (or something).