سازماندهی فایل های YAML با ایجاد دایرکتوری هایی مانند 'config/x' در Rails

Summarize this content to 400 words in Persian Lang
سلام! در این پست، روشی ساده و در عین حال موثر برای سازماندهی فایل های پیکربندی در برنامه Rails را به اشتراک می گذارم. همانطور که پروژه Rails شما رشد می کند، شما را حفظ می کند config/ دایرکتوری تمیز و قابل مدیریت اهمیت فزاینده ای پیدا می کند. ما چگونگی ایجاد دایرکتوری های سفارشی را بررسی خواهیم کرد config/x و با استفاده از config_for می تواند فایل های پیکربندی YAML شما را برای مدیریت و نگهداری آسان تر کند.

فهرست مطالب

اعمال نفوذ Rails.configuration و config_for برای تنظیمات سفارشی

درک کردن config.x.something در مقابل config.something

مشکل: خیلی زیاد config/*.yml فایل ها

چرا پیش فرض config/ دایرکتوری به هم ریخته می شود

راه حل: سازماندهی تنظیمات برنامه سفارشی با config/x/*.yml

اعمال نفوذ Rails.configuration و config_for برای تنظیمات سفارشی

اول، بیایید در مورد صحبت کنیم Rails.configuration و config_for.

این ویژگی‌ها در Rails 4.2 به‌عنوان جایگزینی برای سنگ‌های قیمتی مانند جواهر پیکربندی (نوستالژیک) یا جواهر settings_logic (همچنین نوستالژیک) معرفی شدند.

در اینجا گزیده ای از راهنمای Rails 7.0 آمده است:

Rails.configuration

برای تنظیم تنظیمات، آنها را در آن تعریف می کنید config/application.rb یا فایل های مشابه:

config.x.payment_processing.schedule = :daily
config.x.payment_processing.retries = 3
config.super_debugger = true

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

شما می توانید این مقادیر را از هر جایی در برنامه خود مانند این بازیابی کنید:

Rails.configuration.x.payment_processing.schedule # => :daily
Rails.configuration.x.payment_processing.retries # => 3
Rails.configuration.x.payment_processing.not_set # => nil
Rails.configuration.super_debugger # => true

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در حال حاضر، در مورد config_for

config_for روشی برای بارگذاری فایل های YAML است.

اغلب برای تنظیم مقادیر استفاده می شود Rails.configuration.

به عنوان مثال، اگر یک فایل YAML مانند این دارید:

# config/payment.yml
production:
environment: production
merchant_id: production_merchant_id
public_key: production_public_key
private_key: production_private_key

development:
environment: sandbox
merchant_id: development_merchant_id
public_key: development_public_key
private_key: development_private_key

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

می توانید این مقادیر را در آن تنظیم کنید config/application.rb به شرح زیر:

# config/application.rb
module MyApp
class Application < Rails::Application
config.payment = config_for(:payment)
end
end

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در این مورد، مقادیری مانند زیر را بازیابی خواهید کرد:

Rails.configuration.payment[‘merchant_id’] # => production_merchant_id or development_merchant_id

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

شما همچنین می توانید مقدار را با استفاده از config.x.payment = config_for(:payment) اگر ترجیح می دهید، مانند این:

# config/application.rb
module MyApp
class Application < Rails::Application
config.x.payment = config_for(:payment)
end
end

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

سپس، می توانید مقادیر را مانند زیر بازیابی کنید:

Rails.configuration.x.payment[‘merchant_id’] # => production_merchant_id or development_merchant_id

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

چه فرقی با هم دارند config.x.something و config.something?

از نقطه نظر پیاده سازی، تفاوت اصلی در این است config.x.something اجازه لانه سازی را می دهد.

# Example
config.x.payment_processing.schedule = :daily

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

به غیر از آن، راهنمای Rails هیچ تفاوت عمده ای را پیشنهاد نمی کند. با این حال، من شخصاً دوست دارم اضافه کنم x حسی سفارشی و محلی به آن می دهد، شبیه به هدرهای سفارشی HTTP.

مشکل: خیلی زیاد config/*.yml فایل ها

چه استفاده کنید x یا نه، همانطور که از این روش ها استفاده می کنید، در نهایت با فایل های YAML زیادی مواجه خواهید شد config/ دایرکتوری

در اینجا یک مثال از آنچه که config/ پوشه ممکن است به شکل زیر باشد:

application.rb
bar.yml
baz.yml
boot.rb
cable.yml
corge.yml
database.yml
environment.rb
environments/
foo.yml
fred.yml
garply.yml
grault.yml
initializers/
locales/
newrelic.yml
plugh.yml
puma.rb
quux.yml
qux.yml
routes.rb
sidekiq.yml
spring.rb
storage.yml
thud.yml
waldo.yml
webpack/
webpacker.yml

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

آشفتگی

مشکل تعداد فایل ها نیست. مسئله این است که تمایز بین فایل‌های YAML ارائه شده توسط Rails یا gems شخص ثالث و تنظیمات سفارشی شما دشوار می‌شود.

به عنوان مثال:

config/cable.yml و config/database.yml از ریل می آیند

config/sidekiq.yml از گوهر sidekiq می آید.

config/newrelic.yml از جواهر New Relic می آید.
همه دیگر config/*.yml فایل‌ها تنظیمات برنامه سفارشی هستند که با استفاده از آن تنظیم می‌شوند config_for.

به طور خلاصه، اگر بخواهیم در مورد پرونده های موجود در config/، ممکن است به شکل زیر باشد:

config/
├── application.rb
├── database.yml # from Rails
├── cable.yml # from Rails
├── sidekiq.yml # from Sidekiq gem
├── newrelic.yml # from New Relic gem
├── bar.yml # custom app config
└── foo.yml # custom app config

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اکنون آن را با یک ساختار تمیزتر مقایسه کنید config/x/:

config/
├── application.rb
├── x/ # custom app configs live here
│ ├── bar.yml
│ └── foo.yml
├── database.yml
└── cable.yml

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

حتی توسعه دهندگان باتجربه نیز می توانند در یک نگاه تشخیص بین این فایل ها مشکل داشته باشند.

راه حل: سازماندهی تنظیمات برنامه سفارشی با config/x/*.yml

این پیشنهاد من است: config_for در واقع می تواند فایل ها را از دایرکتوری های دیگری بارگذاری کند config/. این در Rails 5.0 تغییر کرد (تعهد مربوطه را اینجا ببینید).

بنابراین، ما می توانیم بازنویسی کنیم config/application.rb مانند این:

# config/application.rb
module MyApp
class Application < Rails::Application
config.x.bar = config_for(Rails.root.join(‘config/x/bar.yml’))
config.x.baz = config_for(Rails.root.join(‘config/x/baz.yml’))
config.x.corge = config_for(Rails.root.join(‘config/x/corge.yml’))
# …snip…
config.x.waldo = config_for(Rails.root.join(‘config/x/waldo.yml’))
end
end

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

با انجام این کار، ما به راحتی می توانیم بین فایل های YAML ارائه شده توسط Rails یا gems شخص ثالث و تنظیمات سفارشی خود تمایز قائل شویم.

در اینجا نحوه config/ پوشه به نظر می رسد:

# config/
application.rb
boot.rb
cable.yml # From Rails
database.yml # From Rails
environment.rb
environments/
initializers/
locales/
newrelic.yml # From New Relic gem
puma.rb
routes.rb
sidekiq.yml # From Sidekiq gem
spring.rb
storage.yml # From Rails
webpack/
webpacker.yml # From Rails
x/

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

و در config/x/:

# config/x/
bar.yml # Custom for this Rails app
baz.yml # Custom for this Rails app
corge.yml # Custom for this Rails app
foo.yml # Custom for this Rails app
fred.yml # Custom for this Rails app
garply.yml # Custom for this Rails app
grault.yml # Custom for this Rails app
plugh.yml # Custom for this Rails app
quux.yml # Custom for this Rails app
qux.yml # Custom for this Rails app
thud.yml # Custom for this Rails app
waldo.yml # Custom for this Rails app

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

با جدا کردن فایل ها به این صورت همه چیز خیلی واضح تر می شود!

نتیجه گیری

در این پست، نحوه ایجاد a را مورد بحث قرار دادیم config/x دایرکتوری می تواند به شما کمک کند تا فایل های پیکربندی سفارشی YAML را با کارایی بیشتری در Rails سازماندهی کنید. با جدا کردن تنظیمات خاص برنامه از پیکربندی های شخص ثالث و ارائه شده توسط چارچوب، نه تنها مدیریت پایگاه کد خود را آسان تر می کنید، بلکه وضوح را برای توسعه دهندگانی که نیاز به درک سیستم در یک نگاه دارند، بهبود می بخشید.

این ساختار یک رویکرد تمیزتر و مدولارتر را تشویق می کند، که به ویژه برای مقیاس بندی و نگهداری برنامه های ریل بزرگ مفید است.

config.x.payment_processing.schedule = :daily
config.x.payment_processing.retries  = 3
config.super_debugger = true

Rails.configuration.x.payment_processing.schedule # => :daily
Rails.configuration.x.payment_processing.retries  # => 3
Rails.configuration.x.payment_processing.not_set  # => nil
Rails.configuration.super_debugger                # => true

# config/payment.yml
production:
  environment: production
  merchant_id: production_merchant_id
  public_key:  production_public_key
  private_key: production_private_key

development:
  environment: sandbox
  merchant_id: development_merchant_id
  public_key:  development_public_key
  private_key: development_private_key

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.payment = config_for(:payment)
  end
end

Rails.configuration.payment['merchant_id'] # => production_merchant_id or development_merchant_id

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.x.payment = config_for(:payment)
  end
end

Rails.configuration.x.payment['merchant_id'] # => production_merchant_id or development_merchant_id

# Example
config.x.payment_processing.schedule = :daily

application.rb
bar.yml
baz.yml
boot.rb
cable.yml
corge.yml
database.yml
environment.rb
environments/
foo.yml
fred.yml
garply.yml
grault.yml
initializers/
locales/
newrelic.yml
plugh.yml
puma.rb
quux.yml
qux.yml
routes.rb
sidekiq.yml
spring.rb
storage.yml
thud.yml
waldo.yml
webpack/
webpacker.yml

config/
├── application.rb
├── database.yml   # from Rails
├── cable.yml      # from Rails
├── sidekiq.yml    # from Sidekiq gem
├── newrelic.yml   # from New Relic gem
├── bar.yml        # custom app config
└── foo.yml        # custom app config

config/
├── application.rb
├── x/           # custom app configs live here
│   ├── bar.yml
│   └── foo.yml
├── database.yml
└── cable.yml

# config/application.rb
module MyApp
  class Application < Rails::Application
    config.x.bar   = config_for(Rails.root.join('config/x/bar.yml'))
    config.x.baz   = config_for(Rails.root.join('config/x/baz.yml'))
    config.x.corge = config_for(Rails.root.join('config/x/corge.yml'))
    # ...snip...
    config.x.waldo = config_for(Rails.root.join('config/x/waldo.yml'))
  end
end

# config/
application.rb
boot.rb
cable.yml        # From Rails
database.yml     # From Rails
environment.rb
environments/
initializers/
locales/
newrelic.yml     # From New Relic gem
puma.rb
routes.rb
sidekiq.yml      # From Sidekiq gem
spring.rb
storage.yml      # From Rails
webpack/
webpacker.yml    # From Rails
x/

# config/x/
bar.yml          # Custom for this Rails app
baz.yml          # Custom for this Rails app
corge.yml        # Custom for this Rails app
foo.yml          # Custom for this Rails app
fred.yml         # Custom for this Rails app
garply.yml       # Custom for this Rails app
grault.yml       # Custom for this Rails app
plugh.yml        # Custom for this Rails app
quux.yml         # Custom for this Rails app
qux.yml          # Custom for this Rails app
thud.yml         # Custom for this Rails app
waldo.yml        # Custom for this Rails app