Fix non-compiling Button examples in LLMs.md - #337
Open
maragubot wants to merge 2 commits into
Open
Conversation
Both examples collided with `html.Button`: the type safety one redeclared it under a dot-import, and the testing one passed it a string. They now use a `VariantButton` component that compiles and renders what the test asserts.
The collision applies package-wide, not just in the file with the dot-import, and an aliased import avoids it.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #337 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 6 6
Lines 639 639
=========================================
Hits 639 639 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
What was found
Two Go examples in
LLMs.mdunder "Best Practices" don't compile.The "Type Safety" example declared
func Button(variant ButtonVariant, text string) Nodein a file that dot-importsmaragu.dev/gomponents/html, which already exportsButton:Its body also called
Button(...)recursively rather than the element. The "Testing" example then calledButton("Click me"), passing a string tohtml.Button(children ...g.Node), and asserted the output<button>Click me</button>.This matters more here than in ordinary docs:
LLMs.mdexists so language models can learn the library, so a broken example is copied forward into generated code rather than caught by a reader.What was fixed
Renamed the component to
VariantButtonin both examples so it no longer collides with the element, and added a note explaining the collision and how to avoid it. Rewrote the testing example to renderVariantButton, check theRendererror, and assert the output the component actually produces:I verified this by extracting the two code blocks straight out of the committed
LLMs.mdand compiling them against this branch, so the doc itself is what was tested rather than a retyping of it. The note's two claims were checked the same way: declaringButtonin a different file of the package with aliased imports still fails, and dropping the dot-import lets it build.Only prose and example code changed; no library code is touched.
Review notes
Two competing reviewers confirmed the new examples compile and that the asserted HTML is byte-exact. Both independently found that
LLMs.mdcontains further broken examples of the same kind, which this PR deliberately leaves alone to stay a single-issue change:Thead/Tbodyin the Tables example are undefined; the real names areTHeadandTBody. Both reviewers called this the most damaging one left, since those are exactly the names a model would guess.Navsnippet) has a syntax error from a missing trailing comma.Page("Welcome!")is called against aPage()defined with no parameters earlier in the file.ServeHTTPperformance example declares a method onHandler, which is a func type and so cannot take a receiver.One reviewer also noted that the
Layoutexample callsHeader(),Main()andFooter()expecting user components, but under its dot-import those bind to the HTML elements and render empty tags. That is the silent version of the bug fixed here and deserves its own change.Worth noting the root cause: nothing compiles these snippets, so the class recurs. A check that extracts and builds the
goblocks inLLMs.mdwould catch all of the above.