Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support configuration via env #196

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

skryukov
Copy link
Contributor

This PR generalizes and improves upon the implementation from #172.

There are a couple of things I wanted to address regarding #172:

  • Usually ENV values take precedence over values set in the initializer
  • I would love to see a more general approach to control configuration values (e.g., ssr_enabled)

Having the first point in mind, I needed to choose a strategy to prioritize gem defaults, global user configuration, env options, and finally controller-level configuration.

This is what I came up with, trying to follow the principle of least surprise:
InertiaRails.defaults → InertiaRails.configure → ENV → controller-level config

Example:

# initializer
InertiaRails.configure do |c|
  c.ssr_enabled = false
  c.ssr_url = 'localhost:1234'
end

# env
ENV['INERTIA_SSR_ENABLED'] = 'true'
ENV['INERTIA_SSR_URL'] = 'vite:1234'

# controller-level
class PublicController < ApplicationController
end

class DashboardController < ApplicationController
  inertia_config(ssr_enabled: false)
end

With this configuration, SSR will be enabled for PublicController but disabled for DashboardController.

@skryukov skryukov force-pushed the support-configuration-via-env branch from bdfc30f to a567744 Compare February 18, 2025 12:10
@skryukov skryukov force-pushed the support-configuration-via-env branch from a567744 to dca5702 Compare February 18, 2025 12:14
@brodienguyen
Copy link
Contributor

I am sold with this approach. Love your work as always bro @skryukov
Happy to close my PR to focus on pushing this approach forward.

@BrandonShar
Copy link
Collaborator

Usually ENV values take precedence over values set in the initializer

Is this the most common pattern? I would've guessed that manually set options in an initializer should override the environment because they're explicitly set. Everything else makes perfect sense to me!

@skryukov
Copy link
Contributor Author

I think you're right @BrandonShar, that will be more Rails-y, will update the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants