RAILS_ENV determines which Webpacker YAML settings are used and NODE_ENV determines which webpack configuration is used.

This finally brings us to the use case for NODE_ENV=test: JavaScript unit testing By this I mean executing tests, written in JavaScript, against your application JavaScript code within a Node.js process.

You can also just throw<% yield :javascript_packs %>somewhere in your layout, and use<%= content_for :javascript_packs do %><%= javascript_pack_tag 'visitor' %><% end %>

(Note that you rarely want to deal with Time.now, or Date.today, in order to honor the application time zone please always use Time.current and Date.current.)

The best way to do this is create a new Rails environment, profile.rb.

Actually, thats the one thing I’ve always thought Middleman got better than Rails: instead of eg, calling ‘render :admin’ in the general layout, you would ‘wrap_layout :application’ inside the specific (admin) one. It’s much more ergonomic this way.

I ran in to what I thought was this issue, but I was using fragment caching. Since the partial was not executed again, the content_for was not called. content_for could be written differently to handle this.

As mentioned in StateMachines::Machine#state, you can define behaviors, like validations, that only execute for certain states. One important caveat here is that, due to a constraint in ActiveRecord's validation framework, custom validators will not work as expected when defined to run in multiple states.

For Rails 5, note that protect_from_forgery is no longer prepended to the before_action chain, so if you have set authenticate_user before protect_from_forgery, your request will result in "Can't verify CSRF token authenticity." To resolve this, either change the order in which you call them, or use protect_from_forgery prepend: true.

Rails also adds a test method that takes a test name and a block. It generates a normal Minitest::Unit test with method names prefixed with test_. So you don't have to worry about naming the methods, and you can write something like:

The translated model name, translated attribute name, and value are always available for interpolation as model, attribute and value respectively.

There are few ways to build forms with objects that don't inherit from Active Record, as follows:

the /rails/info/properties page

If you ever need to work with external translators, it’s a bit of a pain sending both your YML files and a bunch of views like index.en.html.erb. For one thing, you need some code to find all those files and send them, and put them back after receiving the translations. For another, your translator must respect the markup and code of the template, and know not to translate them. And if you want to use tools like WebTranslateIt, it’s easier to stick to YML.

Action View has the ability to render different templates depending on the current locale.For example, suppose you have an ArticlesController with a show action. By default, calling this action will render app/views/articles/show.html.erb. But if you set I18n.locale = :de, then app/views/articles/show.de.html.erb will be rendered instead. If the localized template isn't present, the undecorated version will be used. This means you're not required to provide localized views for all cases, but they will be preferred and used if available.

ActionController and ActionMailer default include AbstractController::Rendering directly or indirectly (ActionController::Metal::Rendering). AbstractController::Rendering uses ActionView as default library for its template rendering engine and includes AbstractController::ViewPaths and an instance of I18n proxy to find localized views. To learn more i'd like to refer to the ActionPack source code on github. To get to the point. ActionView allows you to use localisation in your templates: See Rails guide: Action View Overview , Chapter Localized views.

For several reasons the Simple backend shipped with Active Support only does the "simplest thing that could possibly work" for Ruby on Rails3 ... which means that it is only guaranteed to work for English and, as a side effect, languages that are very similar to English. Also, the simple backend is only capable of reading translations but cannot dynamically store them to any format.That does not mean you're stuck with these limitations, though. The Ruby I18n gem makes it very easy to exchange the Simple backend implementation with something else that fits better for your needs, by passing a backend instance to the I18n.backend= setter.

it comes down to opportunities for code reuse. Will your system re-use more code if you use WordPress and its very usable admin area, myriad of available plugins and themes? Or can you re-use more code by harnessing the object-oriented design, DSLs and good software development practices mecca that is Ruby, Rails and the available libraries and tools?

The :shallow_prefix option adds the specified parameter to the named route helpers:

You can also specify the :shallow option in the parent resource, in which case all of the nested resources will be shallow:

The shallow method of the DSL creates a scope inside of which every nesting is shallow. This generates the same routes as the previous example:

If you need more advanced React-integration, like server rendering, redux, or react-router, see shakacode/react_on_rails, react-rails, and webpacker-react.

This gem also includes a responders controller generator, so your scaffold can be customized to use respond_with instead of default respond_to blocks. From 2.1, you need to explicitly opt-in to use this generator by adding the following to your config/application.rb: config.app_generators.scaffold_controller :responders_controller

Responders don't use valid? to check for errors in models to figure out if the request was successful or not, and relies on your controllers to call save or create to trigger the validations.

Arguably, the rails-team's choice of raising ArgumentError instead of validation error is correct in the sense that we have full control over what options a user can select from a radio buttons group, or can select over a select field, so if a programmer happens to add a new radio button that has a typo for its value, then it is good to raise an error as it is an application error, and not a user error. However, for APIs, this will not work because we do not have any control anymore on what values get sent to the server.

liberal_enum :kind

When the controller creates the user, instead of adding a validation error to the record, it raises an exception. How to avoid this?

I really dislike the reasoning as stated in the issue listed above. Since the value is coming over the wire, it should be treated the same as a freetext input where the expectation is to validate in the model and not the controller. This is especially true in APIs where the developers have even less of a say as far as expected input coming from form data (for example).

In case anyone wants a hack, here is what I came up with.

But now the first line throws an exception ArgumentError: '0' is not a valid audience

At each stage of developing the sample application, we will write small, bite-sized pieces of code—simple enough to understand, yet novel enough to be challenging. The cumulative effect will be a deeper, more flexible knowledge of Rails, giving you a good background for writing nearly any type of web application.

Following the scaffolding approach risks turning you into a virtuoso script generator with little (and brittle) actual knowledge of Rails.

"American Idiot" - Green Day

Now everybody do the propaganda,And sing along to the age of paranoia.

We're not the ones who're meant to follow.

Television dreams of tomorrow.

require 'active_record/connection_adapters/postgis_adapter/railtie'

require 'active_record/connection_adapters/postgis/railtie'