{"id":7065,"date":"2014-07-09T14:36:59","date_gmt":"2014-07-09T11:36:59","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=7065"},"modified":"2021-08-12T12:58:02","modified_gmt":"2021-08-12T09:58:02","slug":"share-rails-configuration-to-javascript","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/share-rails-configuration-to-javascript\/","title":{"rendered":"Share Rails configuration to Javascript"},"content":{"rendered":"\n

The usual way of storing Rails configuration data are YAML files. In one of our previous posts, we talked about proper way of dealing with Rails configuration<\/a>.<\/p>\n\n\n\n

Nowadays, Javascript applications built on top of RESTful API are common practice, and in cases like this configuration data might be duplicated across frontend and backend. We’ve faced this issue in our projects too and decided to extend our global gem<\/a> to make access to Rails configuration from Javascript.<\/p>\n\n\n\n

Installation<\/h2>\n\n\n\n
gem install global\n<\/pre>\n\n\n\n
or add the following line into Gemfile<\/code>:<\/p>\n\n\n\n
gem 'global', '~> 0.1'\n<\/pre>\n\n\n\n
Configuration<\/h2>\n\n\n\n
In addition to default configuration variables:<\/p>\n\n\n\n
Global.configure do |config|\n  config.environment = \"YOUR_ENV_HERE\"\n  config.config_directory = \"PATH_TO_DIRECTORY_WITH_FILES\"\nend\n<\/pre>\n\n\n\n
you should set values related to Javascript:<\/p>\n\n\n\n
Global.configure do |config|\n  config.namespace = \"JAVASCRIPT_OBJECT_NAME\" # default Global\n  config.except = [\"LIST_OF_FILES_TO_EXCLUDE_ON_FRONT_END\"] # default :all\n  config.only = [\"LIST_OF_FILES_TO_INCLUDE_ON_FRONT_END\"] # default []\nend\n<\/pre>\n\n\n\n
All files are excluded by default due to security reasons.<\/p>\n\n\n\n
WARNING!!! Don not include files that contain protected information – like api keys or credentials – because they will be accessible from the Browser console.<\/p>\n\n\n\n
Require global file in application.js<\/code>:<\/p>\n\n\n\n
\/*\n= require global-js\n*\/\n<\/pre>\n\n\n\n
Advanced Configuration<\/h2>\n\n\n\n
In case you need different configurations for different parts of your application, you should create files manually.<\/p>\n\n\n\n
If your application has admin<\/code> and application<\/code> namespace:<\/p>\n\n\n\n
# app\/assets\/javascripts\/admin\/global.js.erb\n<%= Global.generate_js(namespace: \"AdminSettings\", only: %w(admin hosts)) %>\n\n# app\/assets\/javascripts\/admin.js.coffee\n#= require admin\/global\n<\/pre>\n\n\n\n
# app\/assets\/javascripts\/application\/global.js.erb\n<%= Global.generate_js(namespace: \"AppSettings\", except: %w(admin credentials)) %>\n\n# app\/assets\/javascripts\/application.js.coffee\n#= require application\/global\n<\/pre>\n\n\n\n
Usage<\/h2>\n\n\n\n
For instance, you have config file global\/hosts.yml<\/code> with hosts settings for api and web:<\/p>\n\n\n\n
development:\n  web: localhost\n  api: api.localhost\nproduction:\n  web: myhost.com\n  api: api.myhost.com\n<\/pre>\n\n\n\n
After that you have access to Global<\/code> Javascript object with settings from global\/hosts.yml<\/code> file:<\/p>\n\n\n\n
Global.hosts.web\n=> \"localhost\"\n<\/pre>\n\n\n\n
And in production environment:<\/p>\n\n\n\n
Global.hosts.web\n=> \"myhost.com\"\n<\/pre>\n\n\n\n
References<\/h2>\n\n\n\n
For more details, check out the source code and documentation on github<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
The usual way of storing Rails configuration data are YAML files. In one of our previous posts, we talked about proper way of dealing with Rails configuration. Nowadays, Javascript applications built on top of RESTful API are common practice, and in cases like this configuration data might be duplicated across frontend and backend. We’ve faced…<\/p>\n","protected":false},"author":44,"featured_media":9465,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Olexander Paladiy"],"class_list":["post-7065","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/7065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=7065"}],"version-history":[{"count":37,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/7065\/revisions"}],"predecessor-version":[{"id":13956,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/7065\/revisions\/13956"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/9465"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=7065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=7065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=7065"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=7065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}