Skip to content

Conversation

@elalemanyo
Copy link

@elalemanyo elalemanyo commented Sep 22, 2025

Summary

This PR adds environment variable control for debug mode in the ReActionView install generator, allowing any developer to disable debug mode in their own environment without modifying code.

Changes

  • Modified the debug_mode configuration in the install generator to check both Rails.env.development? and the absence of the REACTIONVIEW_DISABLE_DEBUG_MODE environment variable.
  • Debug mode is now enabled only when both conditions are true:
    1. Rails environment is development
    2. `REACTIONVIEW_DISABLE_DEBUG_MODE environment variable is not set (defaults to enabled)

Motivation

Previously, debug mode was hardcoded to be enabled in all development environments. This change allows individual developers to control debug mode through their own environment setup without touching any application code. Each developer can now:

  • Set their own preference via environment variables
  • Disable debug mode when it's not needed for their workflow
  • Avoid modifying shared configuration files
  • Have personalized development environments

Backward Compatibility

✅ This change is fully backward compatible. Debug mode remains enabled by default in development environments, preserving existing behavior unless a developer explicitly chooses to disable it.

Usage

Any developer can disable debug mode in their environment by setting the environment variable to any value:

export REACTIONVIEW_DISABLE_DEBUG_MODE=1
# or
export REACTIONVIEW_DISABLE_DEBUG_MODE=true
# or
export REACTIONVIEW_DISABLE_DEBUG_MODE=yes

No code changes required - just personal environment configuration!

@t27duck
Copy link
Contributor

t27duck commented Sep 23, 2025

I wonder if the inverse would be better:

config.debug_mode = Rails.env.development? && !ENV["REACTIONVIEW_DISABLE DEBUG_MODE"]

This way, you can set this env var to anything such as "1" or "yes" or "TRUE". The presence of a value disables debug mode.

# Enable debug mode in development (adds debug attributes to HTML)
config.debug_mode = Rails.env.development?
config.debug_mode = Rails.env.development? && ENV.fetch("REACTIONVIEW_DEBUG_MODE", "true") == "true"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
config.debug_mode = Rails.env.development? && ENV.fetch("REACTIONVIEW_DEBUG_MODE", "true") == "true"
config.debug_mode = Rails.env.development? && !ENV["REACTIONVIEW_DISABLE_DEBUG_MODE"]

@t27duck Thanks for the feedback! You make a great point about the simplicity of checking for the presence of the environment variable rather than its specific value.

You're absolutely right that this is cleaner - any value ("1", "yes", "TRUE", etc.) would disable debug mode, which is more intuitive and follows common Unix conventions.

My initial implementation was more verbose because I like environment variables that explicitly say what they're doing (like REACTIONVIEW_DEBUG_MODE=false), but at the end of the day, this is really just a matter of taste and your approach is definitely more concise.

The important thing is that we're solving the core problem: allowing individual developers in a team to control debug mode through their personal environment setup without changing code that affects everyone else. Whether someone prefers REACTIONVIEW_DISABLE_DEBUG_MODE=1 or REACTIONVIEW_DEBUG_MODE=false is secondary to having that flexibility.

I'm open to updating the implementation either way 🙂

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think I also like "opt-out" DISABLE approach more, since it's more intuitive.

But also, I'm wondering why you would want to disable it? I get that now in the beginning there might be some bugs and that might be why you'd want to disable it. But ideally, I want as many people to use it so we are able to surface these bugs and can make it better for everyone 🙈

Copy link
Author

@elalemanyo elalemanyo Oct 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcoroth I totally understand your point and I’m also in favor of having it enabled by default so more people use it and we can improve it step by step. 🙌
At the same time, I’ve run into some bugs that might not be so easy to fix quickly, which is why I thought having the option to disable it could be useful in certain cases 😬.

The reason I suggested the disable option is that I’ve run into some issues when using ViewComponent slots (renders_one / renders_many).

I’ve put together a small repo: ReactionView + Bootstrap.

shot2025-10-01 at 15 09 09@2x

One issue I noticed is that the extra HTML that ReactionView injects for the debug console can interfere with CSS selectors. For example, selectors like :first-child, :last-child or adjacent sibling selectors (.selector + .selector) no longer match as expected because the injected elements change the DOM structure. This can cause layouts or designs to break visually 😔.

Sure, it’s definitely something we can help fix (and we will 👍), but just in case, it would be nice to have a way to disable it locally for a moment — that way we can quickly confirm whether the issue comes from ReactionView or the app code itself.

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