Random 'concerns' folders and '.keep' files

Question

I am learning rails.

Somewhere along the line, I noticed that seemingly random folders and files are appearing in my rails app's directory. In some folders there is a concerns folder with a .keep file inside it. The .keep file appears to be empty. In other folders there is no concerns folder but an empty .keep file is present.

Does anyone know what the deal with these files/folders is?

Brunhilda

Answer 1

.keep files are 0 byte files that are there to stop empty folders from being ignored by all sorts of processes. Nothing to worry about.

Tatting

great, thanks! So should I leave them? I was going to delete them if they aren't necessary – Brunhilda

Yes you should keep them around so they are there when you need them. It will also make sure the folders get noticed by your version control system. – Obscenity

Should I put them in my .gitignore? I'd rather not commit empty files. – Sparteine

@Sparteine I would commit them. Not sure what would happen if somebody else were to clone your codebase. – Tatting

Answer 2

.keep files are especially helpful when you want to commit empty directories with git.

Fun fact, the name .keep or .gitkeep is meaningless. you can call the file .foo for the same effect, its merely a readable convention.

The .keep files are also there to aid portage from one vcs to another, preventing the deletion of important directories when you un-merge something that would cause those directories to be empty.

For example, consider a script which attempts to cd dir into a directory that is untracked by git.

It's a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.

Novobiocin

Answer 3

Concerns is a simple but powerful concept. It exists for code reusability. Basically, the idea is to extract common and / or context specific chunks of code in order to clean up the models and avoid them getting too fat and unmanageable.

I would like to specify explicitly that you should use service objects to provide functionality that's not the concern of the specific object. Eg a organisation has many users. Now the admin of organisation needs to export a CSV of all users for this organisation. This code can be placed in organisation model but since its not the responsibility of the organisation object, this code should be placed in a class where u just pass the organisation object and it returns the CSV of all users.

 class Services::GenerateCsv
     def self.get_users org
         #add logic the fetch users for the org and generate the CSV and return the CSV data
     end
 end

Whenever you need CSV generation, u can place to that logic in the above class. This approach keeps the object (in this case, the organisation model) clean from the code that shouldn't be its responsibility. A general principle that I follow is: if the code it's modifying the self object, move the code to a service object.

Note: Your question was regarding concerns but I thought of adding some extra stuff that I follow to keep the code base clean and manageable since it might help fellow programmers. That above approach is debatable.

Antione