Ruby: Analyze and resolve Action View render calls#1663
Merged
Conversation
commit: |
🌿 Interactive Playground and Documentation PreviewA preview deployment has been built for this pull request. Try out the changes live in the interactive playground: 🌱 Grown from commit ✅ Preview deployment has been cleaned up. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 pull request introduces ActionView render call analysis, a system that statically traces
rendercalls across ERB templates to build dependency graphs, detect unresolved partials, find unused partials, and verify full resolvability of entry points.Motivation
Herb needs to understand the render dependencies between templates to support runtime reactivity, Herb dev server patches, and for potential compile-time optimizations.
When a partial changes (whether its file on disk during development or its underlying state at runtime) we need to know which entry points are affected and may need re-rendering. The render graph gives us that reverse lookup, enabling the dev server to notify the right clients and future reactive rendering to trace exactly which templates to update.
Beyond reactivity, static resolution of render calls is a prerequisite for compile-time partial inlining (see #654). If we can prove at compile time that a render call resolves unambiguously to a single partial file, we can eliminate the expensive runtime file lookup entirely either by inlining the partial's content directly or by rewriting the call to ActionView's internal compiled method.
The
fully_resolvable?API provides exactly that guarantee: it walks the full render tree and confirms there are no dynamic or unresolved gaps that would make such optimizations unsafe.Example Output
bundle exec herb actionview graph app/views/profiles/show.html.erbbundle exec herb actionview graph app/views/profiles/_header.html.erbbundle exec herb actionview checkRuby API