Engine: Add support for disabling debug spans in ERBBlockNode via comments #977
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is an attempt to address the issue discussed in #605.
When rendering ERB output inside
content_for, it is not possible to know at template-analysis time whether the content will eventually be used in a context where emitting debug spans is invalid (for example, inside a<title>element).Because of this, the current behavior can result in broken HTML depending on how and where the
content_forcontent is consumed.To address this, this PR introduces a way for ERB template authors to explicitly opt out of debug spans at the ERB block level by adding a
# herb:debug disablecomment to the block.When such a comment is present,
DebugVisitorskips wrapping ERB expressions within thatERBBlockNode.This doesn’t fully solve the question of a good syntax for disabling debug spans on individual
<%=expressions, but it provides a practical workaround for the original issue without relying on fragile inline comment placement.Regarding documentation: I did not add any documentation changes in this PR. The herb repository itself does not currently document debug mode, and it seems more appropriate for this behavior to be documented on the reactionview side (for example, in https://reactionview.dev/guides/debug-mode ).
If this approach doesn’t feel right, please feel free to say so — I’m very open to feedback or alternative directions.