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

Merged
merged 2 commits into from
Mar 4, 2025

Conversation

skryukov
Copy link
Contributor

@skryukov skryukov commented Feb 18, 2025

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

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 → ENV → InertiaRails.configure → controller-level config

Example:

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

# env
ENV['INERTIA_SSR_ENABLED'] = 'false'
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 2 times, most recently 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.

@skryukov skryukov force-pushed the support-configuration-via-env branch 2 times, most recently from 80dc3e6 to af63eab Compare March 1, 2025 10:06
@skryukov skryukov force-pushed the support-configuration-via-env branch from af63eab to 747d621 Compare March 1, 2025 10:07
@bknoles
Copy link
Collaborator

bknoles commented Mar 3, 2025

Just to confirm, this one is ready to go yea? Last commit looks to resolve the conversation nicely!

Would be nice to get this into the docs after we get it released!

@skryukov
Copy link
Contributor Author

skryukov commented Mar 3, 2025

Yup, it's ready 👍

@bknoles bknoles merged commit f59f324 into inertiajs:master Mar 4, 2025
17 checks passed
@skryukov skryukov deleted the support-configuration-via-env branch March 4, 2025 08:39
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.

4 participants