I like to keep things organized in my applications and since I have only been coding in ROR for a year. I have known how to use the app/controllers/concerns directory for custom modules to be included in a controller.
This is great however I am wondering if there is a way to add sub folders to the concerns folder to allow for better organization.
For example app/controllers/concerns/members/profile_methods.rb and the module is named 'ProfileMethods'. If I include 'ProfileMethods' RubyMine see's the module and allows me to include it, including offering it as an option in the tooltip pane. However the Rails Server says that 'ProfileMethods' is an undefined constant if it is in a sub folder of app/controllers/concerns .
Is there something I have to add to the rails application configuration? Any input would be great as it seems a little illogical that you could not further organize the concerns directory with sub folders.
The best way to keep things organized is to name the module the following way. That way you have your code organized in both files and code itself.
module Members
module ProfileMethods
extend ActiveSupport::Concern
...
end
end
This way it will load your modules fine. Other one option is to tweak eager_load_paths in config/application.rb for instance.
Related
I'm trying to put service objects into app/services folder but reference them via Services::SomeModel::SomeClass to better organize my code (the project is pretty large).
# app/services/tasks/create.rb
module Services
module Tasks
class Create
# ...
end
end
end
However, because of the way Rails loads the files, app/services is treated like a base folder and Rails keeps wanting the classes to be defined as ::Tasks::Create instead of ::Services::Tasks::Create.
I can solve this by placing my service objects in a subdirectory, like app/classes/services and then referencing them via ::Services::Tasks::Create, but I would prefer to have the /services folder in the /app directory itself.
I'm not a huge fan of the convention some use with services, naming them ::Tasks::CreateService. The whole reason I'm namespacing them the way I am is so anyone can look at the code and understand where the related files are located and to keep everything organized.
I've tried playing with auto_load in the config/application.rb file but that doesn't seem to work, since Rails is already pre-loading the files in app/* (that's my understanding).
Is there a way to reference service objects via ::Services::Model::Action and have the files located in app/services/model/action.rb?
I am working on a project where the current developers have put their "Plain Old Ruby Objects" in the models directory of our Rails app.
I have seen most examples online where the PORO files go inside lib instead, but some say models.
Is there even a logical / specific reason why people put them in the models directory over the lib directory?
"Idiomatically" the models directory intended for code used to hold state. Most of the time this would be ActiveRecord subclasses corresponding to database tables. However frequently people put other stuff in the models directory. One thing often seen are code dropped here in order to take advantage of auto-reloading. (the lib dir doesn't normally auto-reload)
Based on the Getting Started Rails guide, the app/models/ directory is pretty much anything, whereas lib/ is for modules that are used across the entire app (e.g. extensions).
As #seand said, yes, one advantage is that the app/models/ directory automatically reloads, but I tend to think of it as any class that "interacts with other classes" should live in app/models/, with the only exception being a service class (which I tend to think of as "a class which manipulates the state of another class"), which I tend to put into app/services/.
I know a lot of developers would disagree with me - many I've talked to even create a separate directory namespaced to their app (e.g. if your app is named "MyBlog", they would create an app/myblog directory for any object not explicitly backed by the database, but not a module or a service class either.
That said, I think ultimately it boils down to a) personal preference and b) where you feel is best to place the PORO with respect to your app.
There is no hard and fast rule on where to put POROs. The rails community has been hashing this out for a while now. At one point the convention was to put stuff in the concerns directory but that seems to have fallen out of favor with some folks.
One rule of thumb for the difference between /lib and app/{blah} is that code in the /lib folder is code that you presumably can reuse across several projects e.g. general purpose class or utilities. for example if you have some custom monkey patches to core ruby or rails classes that you will use in multiple projects, a good place to but them would be in the lib folder. Anything in app/{blah} should pertain specifically to current project.
One way to think of lib folder is as the poor cousin of plugins and gems.
Just my 2 cents on the subject
I'm developing a Rails engine, and so I've taken some looks on existing ones. I noticed that many of them have files in app, but also in lib and vendor.
It's clear to me that I should put any code that should be replaceable by the host app into the app folder (e.g. when having a model app/user.rb, the host app can easily have its own app/user.rb file and use this one instead of the engine one's).
But I'm unsure, when I have to put stuff in to lib, and when into vendor? I thought, that in vendor, I should only put "external" code from other developers or projects, that I want to use in my project, and in lib I put my own additional libraries that I'm actually working on in the project. But why, for example, does WiceGrid put stuff into its wice_grid/vendor/assets directory? It doesn't look to me like external code, but code that is developed only for WiceGrid and hence should be in the lib directory?
Update
While experimenting a bit, I noticed that all code in the lib folder is not reloaded while developing the engine (I guess the same is the case for the vendor directory), so I should put them into a folder within app, but where exactly?
For example, I have a file lib/iq_list_controller.rb that holds some class and instance methods for ApplicationController which I mix into it in engine.rb like this:
initializer "wice_grid_railtie.configure_rails_initialization" do |app|
ActiveSupport.on_load(:action_controller) do
extend IqList::Controller::ClassMethods
include IqList::Controller::InstanceMethods
end
end
Where should I put this file so Ruby properly finds it?
Regarding the development reloading issue, if the lib folder is a natural home for your files, then add it to Rails' load path with something like:
module MyEngine
class Engine < ::Rails::Engine
config.autoload_paths << File.expand_path("../../lib", __FILE__)
end
end
Regarding the specific case of vendor assets, it seems reasonable to place your engine's assets in app/assets, where they will be found by the host Rails app.
if you want things to be autoloaded then put them in /app. Otherwise I think that anything in /lib should be manually required. I generally believe that autoloading the lib folder is bad practice.
your basic code for MVC comes in app folder.now suppose you have a generic method/module which is frequently used,so to implement DRYness for your code...all generic and common utilities can be simply put in lib folder.
theres a beautiful explaination when to use lib and using lib folder in rails
Since the latest Rails 3 release is not auto-loading modules and classes from lib anymore,
what would be the best way to load them?
From github:
A few changes were done in this commit:
Do not autoload code in *lib* for applications (now you need to explicitly
require them). This makes an application behave closer to an engine
(code in lib is still autoloaded for plugins);
As of Rails 2.3.9, there is a setting in config/application.rb in which you can specify directories that contain files you want autoloaded.
From application.rb:
# Custom directories with classes and modules you want to be autoloadable.
# config.autoload_paths += %W(#{config.root}/extras)
# Autoload lib/ folder including all subdirectories
config.autoload_paths += Dir["#{config.root}/lib/**/"]
Source: Rails 3 Quicktip: Autoload lib directory including all subdirectories, avoid lazy loading
Please mind that files contained in the lib folder are only loaded when the server is started. If you want the comfort to autoreload those files, read: Rails 3 Quicktip: Auto reload lib folders in development mode. Be aware that this is not meant for a production environment since the permanent reload slows down the machine.
The magic of autoloading stuff
I think the option controlling the folders from which autoloading stuff gets done has been sufficiently covered in other answers. However, in case someone else is having trouble stuff loaded though they've had their autoload paths modified as required, then this answer tries to explain what is the magic behind this autoload thing.
So when it comes to loading stuff from subdirectories there's a gotcha or a convention you should be aware. Sometimes the Ruby/Rails magic (this time mostly Rails) can make it difficult to understand why something is happening. Any module declared in the autoload paths will only be loaded if the module name corresponds to the parent directory name. So in case you try to put into lib/my_stuff/bar.rb something like:
module Foo
class Bar
end
end
It will not be loaded automagically. Then again if you rename the parent dir to foo thus hosting your module at path: lib/foo/bar.rb. It will be there for you. Another option is to name the file you want autoloaded by the module name. Obviously there can only be one file by that name then. In case you need to split your stuff into many files you could of course use that one file to require other files, but I don't recommend that, because then when on development mode and you modify those other files then Rails is unable to automagically reload them for you. But if you really want you could have one file by the module name that then specifies the actual files required to use the module. So you could have two files: lib/my_stuff/bar.rb and lib/my_stuff/foo.rb and the former being the same as above and the latter containing a single line: require "bar" and that would work just the same.
P.S. I feel compelled to add one more important thing. As of lately, whenever I want to have something in the lib directory that needs to get autoloaded, I tend to start thinking that if this is something that I'm actually developing specifically for this project (which it usually is, it might some day turn into a "static" snippet of code used in many projects or a git submodule, etc.. in which case it definitely should be in the lib folder) then perhaps its place is not in the lib folder at all. Perhaps it should be in a subfolder under the app folder· I have a feeling that this is the new rails way of doing things. Obviously, the same magic is in work wherever in you autoload paths you put your stuff in so it's good to these things. Anyway, this is just my thoughts on the subject. You are free to disagree. :)
UPDATE: About the type of magic..
As severin pointed out in his comment, the core "autoload a module mechanism" sure is part of Ruby, but the autoload paths stuff isn't. You don't need Rails to do autoload :Foo, File.join(Rails.root, "lib", "my_stuff", "bar"). And when you would try to reference the module Foo for the first time then it would be loaded for you. However what Rails does is it gives us a way to try and load stuff automagically from registered folders and this has been implemented in such a way that it needs to assume something about the naming conventions. If it had not been implemented like that, then every time you reference something that's not currently loaded it would have to go through all of the files in all of the autoload folders and check if any of them contains what you were trying to reference. This in turn would defeat the idea of autoloading and autoreloading. However, with these conventions in place it can deduct from the module/class your trying to load where that might be defined and just load that.
Warning: if you want to load the 'monkey patch' or 'open class' from your 'lib' folder, don't use the 'autoload' approach!!!
"config.autoload_paths" approach: only works if you are loading a class that defined only in ONE place. If some class has been already defined somewhere else, then you can't load it again by this approach.
"config/initializer/load_rb_file.rb" approach: always works! whatever the target class is a new class or an "open class" or "monkey patch" for existing class, it always works!
For more details , see: https://stackoverflow.com/a/6797707/445908
Very similar, but I think this is a little more elegant:
config.autoload_paths += Dir["#{config.root}/lib", "#{config.root}/lib/**/"]
In my case I was trying to simply load a file directly under the lib dir.
Within application.rb...
require '/lib/this_file.rb'
wasn't working, even in console and then when I tried
require './lib/this_file.rb'
and rails loads the file perfectly.
I'm still pretty noob and I'm not sure why this works but it works. If someone would like to explain it to me I'd appreciate it :D I hope this helps someone either way.
I had the same problem. Here is how I solved it. The solution loads the lib directory and all the subdirectories (not only the direct). Of course you can use this for all directories.
# application.rb
config.autoload_paths += %W(#{config.root}/lib)
config.autoload_paths += Dir["#{config.root}/lib/**/"]
As of Rails 5, it is recommended to put the lib folder under app directory or instead create other meaningful name spaces for the folder as services , presenters, features etc and put it under app directory for auto loading by rails.
Please check this GitHub Discussion Link as well.
config.autoload_paths does not work for me. I solve it in other way
Ruby on rails 3 do not automatic reload (autoload) code from /lib folder. I solve it by putting inside ApplicationController
Dir["lib/**/*.rb"].each do |path|
require_dependency path
end
If only certain files need access to the modules in lib, just add a require statement to the files that need it. For example, if one model needs to access one module, add:
require 'mymodule'
at the top of the model.rb file.
Spell the filename correctly.
Seriously. I battled with a class for an hour because the class was Governance::ArchitectureBoard and the file was in lib/governance/architecture_baord.rb (transposed O and A in "board")
Seems obvious in retrospect, but it was the devil tracking that down. If the class is not defined in the file that Rails expects it to be in based on munging the class name, it is simply not going to find it.
There are several reasons you could have problems loading from lib - see here for details - http://www.williambharding.com/blog/technology/rails-3-autoload-modules-and-classes-in-production/
fix autoload path
threadsafe related
naming relating
...
Some functionality within my rails application looks better as if it was a separate "module", that should be accessed via require. For example, assume it's a function to calculate Fibonacci numbers.
The functionality is independent on rails application and can be reused in other projects, so it should not be stored near application controllers and models, I suppose. But since I'm not going to detach it into separate project, thus placing it to vendor folder seems like not the right thing.
Where should I place it then?
Rails < 5
Before Rails 5, the place to put reusable code such as this is in the lib directory. However you do not need to require anything as lib is already in the load path and it's contents will be loaded during initialization.
If you need to extend an existing class, you define your module first and then include it by sending it as a message to the class you wish to extend, e.g.
module MyExtensions
def self.included base
base.instance_eval do
def my_new_method
…
end
end
end
end
ActiveRecord::Base.send :include, MyExtensions
Rails 5+
The answer is for Rails 5 onwards. TLDR: app/lib is the convention now.
Note all the above answers were written before Rails 5.
\lib
Rails 5 discourages you from using \lib. While you are discouraged from using \lib you still can as long as you add \lib to eagerloading.
# config/application.rb
config.eager_load_paths << Rails.root.join('lib')
\app\lib
Nesting lib off app is now a common convention because any directory off app is automatically eagerloaded.
Reference
Rails guide - autoloading and eagerloading
Stackoverflow - confusing about autoload_paths vs eager_load_paths in rails 4
Stackoverflow - Why use app-lib instead of lib in rails
There is a lib directory in RoR projects which fits well for that purpose - I place common bits of code in form of "libraries" there. Anything from extending ActiveRecord classes to reusable utility methods.
I'll often put stuff in lib, it turns out that anything under lib is in the load path and doesn't need to be required at all.
edit: After Steve's comment, removed the bit about having to require the files. Also, removed a couple requires from some of my code :P