-
Notifications
You must be signed in to change notification settings - Fork 698
update homepage #1863
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
update homepage #1863
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caution
Changes requested ❌
Reviewed everything up to 7f138f0 in 2 minutes and 2 seconds. Click for details.
- Reviewed
353
lines of code in2
files - Skipped
0
files when reviewing. - Skipped posting
5
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. apps/web/client/src/app/_components/hero/create.tsx:286
- Draft comment:
Similar drag event handlers (onDragEnter, onDragOver, onDragLeave, onDrop) are repeated. Consider extracting shared logic to a helper function to reduce duplication. - Reason this comment was not posted:
Confidence changes required:50%
<= threshold50%
None
2. apps/web/client/src/app/_components/hero/index.tsx:22
- Draft comment:
The inside the 'Browse more' link is empty. If it’s meant for an icon, please include it; otherwise, consider removing the element. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a UI-related issue about a missing icon in a link. The rules state not to comment on pure frontend UI changes. While technically correct that the span is empty, this is likely an intentional styling choice or work in progress. The empty span doesn't affect functionality or logic. The empty span could potentially cause unnecessary DOM bloat or confusion for other developers. It might be a legitimate oversight that should be fixed. However, this falls under UI/styling concerns which we're explicitly told to ignore. The author likely has a plan for this element and UI feedback should be handled through other channels. Delete the comment as it relates to pure UI styling concerns which we're instructed to ignore.
3. apps/web/client/src/app/_components/hero/index.tsx:46
- Draft comment:
Magic numbers (e.g., 840, 420, 28) used for positioning the floating circles reduce clarity. Consider extracting these values into constants or document their purpose. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a UI component where the numbers represent specific pixel values for a visual design. The numbers are used consistently within their context - 840 is the container size, 420 is half of that (the center), 28 is half of 56 (the circle size). The mathematical relationships between these numbers make their purpose relatively clear. Moving them to constants wouldn't necessarily make the code more maintainable since they're tightly coupled to the specific visual design. The numbers could be better documented to explain the visual relationships. Moving them to constants could make it easier to adjust the overall scale of the design. While constants could help, the numbers' relationships are mathematically clear and they're only used within this specific UI component. This seems more like a matter of preference than a significant code quality issue. The comment should be deleted. The magic numbers are used in a clear, consistent way for a specific visual design, and extracting them wouldn't significantly improve code quality.
4. apps/web/client/src/app/_components/hero/index.tsx:1
- Draft comment:
The PR description mentions adding framework documentation (Next.js, Remix, Webpack, Babel), but these changes focus on homepage design. Ensure that onboarding documentation updates are included if that was within scope. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%
<= threshold50%
The comment is asking the PR author to ensure that onboarding documentation updates are included, which is similar to asking them to confirm their intention or ensure something is done. This violates the rule against asking the author to ensure something is done or to update the PR description.
5. apps/web/client/src/app/_components/hero/index.tsx:18
- Draft comment:
Typographical error: It looks like "text-1xl" might be a typo. Typically the Tailwind class is "text-xl". Please confirm if this should be corrected. - Reason this comment was not posted:
Marked as duplicate.
Workflow ID: wflow_DB50NytmjqdX3Og5
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
rows={3} | ||
style={{ resize: 'none' }} | ||
/> | ||
<Button |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add an aria-label to the submit button for better accessibility.
@@ -1,15 +1,104 @@ | |||
import { ArrowRightIcon } from 'lucide-react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove the unused import ArrowRightIcon
from lucide-react
.
import { ArrowRightIcon } from 'lucide-react'; |
</h2> | ||
<a | ||
href="#" | ||
className="text-white text-1xl font-normal flex items-center gap-2 border-b border-white/80 pb-1 hover:opacity-80 transition-opacity" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class text-1xl
is non-standard. It likely should be text-xl
as per Tailwind conventions.
className="text-white text-1xl font-normal flex items-center gap-2 border-b border-white/80 pb-1 hover:opacity-80 transition-opacity" | |
className="text-white text-xl font-normal flex items-center gap-2 border-b border-white/80 pb-1 hover:opacity-80 transition-opacity" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caution
Changes requested ❌
Reviewed 2b0e6e6 in 2 minutes and 30 seconds. Click for details.
- Reviewed
402
lines of code in2
files - Skipped
0
files when reviewing. - Skipped posting
7
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. apps/web/client/src/app/_components/hero/create.tsx:242
- Draft comment:
Verify that the decreased padding ('px-2 pt-1' instead of 'p-4') for the container when no images are selected is intentional. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
2. apps/web/client/src/app/_components/hero/create.tsx:257
- Draft comment:
Confirm that reducing the margin-top from 'mt-2' to 'mt-1' on the Textarea container aligns with the intended design. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
3. apps/web/client/src/app/_components/hero/create.tsx:264
- Draft comment:
Removal of the 'pr-12' class from the Textarea may affect spacing for inline elements; please verify that the new layout still provides adequate spacing. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
4. apps/web/client/src/app/_components/hero/index.tsx:141
- Draft comment:
Consider moving the inline keyframe definitions (spin and spin-reverse) to an external CSS file for better maintainability and potential performance benefits. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While moving CSS to external files is generally good practice, this case is debatable. The animations are tightly coupled to this specific component, fairly simple, and keeping them close to the component improves component cohesion and makes the code easier to understand. The performance benefit would be negligible. This feels more like a style preference than a clear improvement. The comment could be right that external CSS files are more maintainable. If these animations were reused across components, having them in a shared file would reduce duplication. However, these animations appear to be component-specific and the current inline approach keeps related code together. The maintenance benefit isn't strong enough to warrant a comment. This comment suggests a style preference rather than a clear improvement. The current implementation is reasonable and doesn't need to be changed.
5. apps/web/client/src/app/_components/hero/index.tsx:113
- Draft comment:
The container's max-width has been updated from 'max-w-7xl' to 'max-w-6xl'. Confirm that this change is intentional for the desired layout. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
6. apps/web/client/src/app/_components/hero/index.tsx:100
- Draft comment:
Typo in FAQ answer: "...the only on that lets you design..." should be "the only one that lets you design...". - Reason this comment was not posted:
Marked as duplicate.
7. apps/web/client/src/app/_components/hero/index.tsx:104
- Draft comment:
Typo in FAQ answer: "hosted off your of your device" should be corrected to "hosted off your device". - Reason this comment was not posted:
Marked as duplicate.
Workflow ID: wflow_qmrYZmwEwEDvj8wi
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
size="icon" | ||
className="w-9 h-9 text-foreground-tertiary group hover:bg-transparent cursor-pointer" | ||
onClick={() => | ||
document.getElementById('image-input')?.click() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using imageRef.current?.click()
instead of document.getElementById('image-input')?.click()
to trigger the file input—this leverages the already defined ref.
document.getElementById('image-input')?.click() | |
imageRef.current?.click() |
}, | ||
{ | ||
question: 'Why would I use Onlook?', | ||
answer: 'When you design in Onlook you design in the real product – in other words, the source of truth. Other products are great for ideating, but Onlook is the only on that lets you design with the existing product and the only one that translates your designs to code instantly.', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo in FAQ answer: 'only on that' should likely be 'only one that' in the answer for 'Why would I use Onlook?'.
answer: 'When you design in Onlook you design in the real product – in other words, the source of truth. Other products are great for ideating, but Onlook is the only on that lets you design with the existing product and the only one that translates your designs to code instantly.', | |
answer: 'When you design in Onlook you design in the real product – in other words, the source of truth. Other products are great for ideating, but Onlook is the only one that lets you design with the existing product and the only one that translates your designs to code instantly.', |
}, | ||
{ | ||
question: 'Who owns the code that I write with Onlook?', | ||
answer: "The code you make with Onlook is all yours. Your code is written locally directly to your files, and isn't hosted off your of your device.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo in FAQ answer: 'hosted off your of your device' should be corrected to hosted off your device
.
answer: "The code you make with Onlook is all yours. Your code is written locally directly to your files, and isn't hosted off your of your device.", | |
answer: "The code you make with Onlook is all yours. Your code is written locally directly to your files, and isn't hosted off your device.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caution
Changes requested ❌
Reviewed 36df1a2 in 1 minute and 59 seconds. Click for details.
- Reviewed
568
lines of code in4
files - Skipped
0
files when reviewing. - Skipped posting
6
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. apps/web/client/src/app/_components/hero/index.tsx:4
- Draft comment:
Unused import: 'ContributorSection' is imported but never used in the component. Remove it if not needed. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While unused imports are generally something we want to clean up, this kind of issue would be caught by ESLint or TypeScript. The rules state not to comment on things that would be obviously caught by the build, including unused imports. This is exactly that case. The import could be intentionally left there for future use as part of an incomplete change. Maybe the build tools aren't properly configured to catch unused imports. Even if the import is intended for future use, leaving unused imports is bad practice and most modern JavaScript/TypeScript toolchains will catch this automatically. No need for a manual review comment. Delete this comment since unused imports are automatically caught by standard build tools.
2. apps/web/client/src/app/page.tsx:2
- Draft comment:
The PR description mentions adding framework documentation (Next.js, Remix, Webpack, Babel) for onboarding docs, but no such content is present. Confirm if documentation sections should be added. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%
<= threshold50%
This comment is asking the PR author to confirm if documentation sections should be added, which violates the rule against asking the author to confirm their intention or to update the PR description. It does not provide a specific code suggestion or point out a specific issue in the code itself.
3. apps/web/client/src/app/page.tsx:124
- Draft comment:
Ensure 'h-100' is a valid Tailwind utility class or a custom class; otherwise consider using a standard height utility. - Reason this comment was not posted:
Confidence changes required:50%
<= threshold50%
None
4. apps/web/client/src/app/_components/top-bar/github.tsx:35
- Draft comment:
Possible typo: 'text-small' might be a mistake. In Tailwind CSS, the standard font size class is 'text-sm'. Please confirm if 'text-small' is intentional or should be corrected to 'text-sm'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a pure UI styling change. The rules explicitly state not to comment on UI or styling changes, as we should assume the author made these changes intentionally. Whiletext-small
might be non-standard Tailwind, the project could have custom Tailwind classes defined. The comment could be pointing out a genuine error that would cause styling issues. Maybe this is more than just a UI change if it breaks the styling system. Per the rules, we should assume UI changes are intentional. Even if this is a typo, it's a pure styling issue that doesn't affect logic. Delete the comment as it violates the rule about not commenting on UI and styling changes.
5. apps/web/client/src/app/page.tsx:32
- Draft comment:
Typo in FAQ answer: "...the only on that lets you design..." should be "...the only one that lets you design...". - Reason this comment was not posted:
Marked as duplicate.
6. apps/web/client/src/app/page.tsx:36
- Draft comment:
Typographical error in FAQ answer: "...hosted off your of your device." Remove the extra 'your' (or rephrase to "hosted off of your device"). - Reason this comment was not posted:
Marked as duplicate.
Workflow ID: wflow_IpxhTHVk5Tz8nQQn
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caution
Changes requested ❌
Reviewed 49b109e in 1 minute and 52 seconds. Click for details.
- Reviewed
132
lines of code in1
files - Skipped
0
files when reviewing. - Skipped posting
3
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. apps/web/client/src/app/_components/landing-page/ContributorSection.tsx:1
- Draft comment:
The PR description (issue 123) mentions onboarding docs, but this file implements a contributor section with animated rings. Please ensure the correct issue/design is linked. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%
<= threshold50%
This comment is asking the PR author to ensure the correct issue/design is linked, which violates the rule against asking the author to update the PR description or confirm their intention. It does not provide a specific code suggestion or ask for a specific test to be written.
2. apps/web/client/src/app/_components/landing-page/ContributorSection.tsx:92
- Draft comment:
Consider moving the inline keyframe definitions to a separate CSS file for improved maintainability. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
3. apps/web/client/src/app/_components/landing-page/ContributorSection.tsx:125
- Draft comment:
File does not end with a newline. Please add a newline at the end of the file. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While having a newline at end of file is good practice, this is something that should be enforced by linting/formatting tools rather than code review comments. It's a very minor issue that doesn't affect functionality. Most modern editors and formatters handle this automatically. The comment is technically correct - there should be a newline. And it's a clear, actionable suggestion. While correct, this is too minor an issue for a PR comment. This should be handled by automated tooling rather than manual review. Delete the comment. This kind of formatting issue should be handled by linters/formatters rather than taking up reviewer and author time.
Workflow ID: wflow_FrzfuZGFrr2xON6G
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
apps/web/client/src/app/_components/landing-page/ContributorSection.tsx
Outdated
Show resolved
Hide resolved
apps/web/client/src/app/_components/landing-page/ContributorSection.tsx
Outdated
Show resolved
Hide resolved
apps/web/client/src/app/_components/landing-page/ContributorSection.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Looks good to me! 👍
Reviewed b9604de in 1 minute and 50 seconds. Click for details.
- Reviewed
4244
lines of code in73
files - Skipped
3
files when reviewing. - Skipped posting
14
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. docs/content/docs/developer/index.mdx:12
- Draft comment:
Consider updating the tech stack description to match the new architecture page (Next.js, Supabase, TailwindCSS, Drizzle) instead of listing Vite. This will improve consistency. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%
<= threshold50%
The comment suggests updating the tech stack description, which is related to documentation or PR description. According to the rules, comments should not ask the PR author to update the PR description or make purely informative comments. This comment seems to fall into that category as it is about consistency in documentation rather than the code itself.
2. docs/package.json:12
- Draft comment:
The React version is set to '^19.1.0'. React 19 is not yet a stable release and may cause unexpected issues. Consider using a stable version (e.g. React 18.x) unless this is intentional. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. packages/ai/src/prompt/provider.ts:64
- Draft comment:
In getHydratedUserMessage, the function checks if content.length === 0. If content is provided as a string rather than an array, ensure that the behavior is as intended. - Reason this comment was not posted:
Confidence changes required:50%
<= threshold50%
None
4. packages/scripts/src/index.ts:44
- Draft comment:
The spawn command for "bun run backend:start" uses shell: true. Verify that this invocation works consistently across target systems. Consider adding error handling or logging if the backend fails to start. - Reason this comment was not posted:
Confidence changes required:50%
<= threshold50%
None
5. apps/web/client/src/app/project/[id]/_components/editor-bar/text-selected.tsx:268
- Draft comment:
There's an extra space in the closing div tag here (</div >
). Consider removing the extra space to be consistent with standard JSX syntax (i.e.,</div>
). - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the extra space, this is an extremely minor formatting issue that doesn't affect functionality. Most code formatters would automatically fix this. The comment creates noise without adding significant value. We should focus on more substantial issues. The comment is factually accurate and points out an inconsistency in the code formatting. Some might argue that consistent formatting is important for code readability. While consistent formatting is important, this is too minor of an issue to warrant a PR comment. It would be better handled by automated tooling like Prettier. Delete this comment as it focuses on an extremely minor formatting issue that doesn't meaningfully impact code quality.
6. apps/web/client/src/app/project/[id]/_components/main.tsx:154
- Draft comment:
Typo: In the CSS calc expression, consider adding spaces around the minus operator for clarity and standards compliance. It should be 'calc(100% - 40px)' instead of 'calc(100%-40px)'. - Reason this comment was not posted:
Comment was on unchanged code.
7. apps/web/client/src/app/project/[id]/_components/main.tsx:167
- Draft comment:
Typo: In the CSS calc expression, consider adding spaces around the minus operator for clarity and standards compliance. It should be 'calc(100% - 40px)' instead of 'calc(100%-40px)'. - Reason this comment was not posted:
Comment was on unchanged code.
8. docs/content/docs/developer/appendix/index.mdx:19
- Draft comment:
Typo: Consider changing "Your api key" to "Your API key" and remove the extra space before the closing angle bracket in the CSB_API_KEY placeholder. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Documentation consistency is good, but this is an extremely minor formatting issue. The current format is perfectly understandable and doesn't impact functionality. The comment feels overly pedantic. Looking at the rest of the file, there's a similar format used in other env var examples (like ANTHROPIC_API_KEY) with spaces and lowercase "api", so this would actually make things less consistent. Documentation consistency could be important for professionalism. Small details can matter for user experience. While consistency matters, this level of nitpicking on documentation formatting creates noise and doesn't materially improve the docs. The current format is clear and matches other examples in the file. Delete this comment as it's too minor and would actually make the docs less internally consistent.
9. docs/content/docs/developer/appendix/index.mdx:25
- Draft comment:
Typo: Consider changing "Your api key" to "Your API key" and remove the extra space before the closing angle bracket in the ANTHROPIC_API_KEY placeholder. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct, this is an extremely minor formatting issue in documentation. The meaning is perfectly clear either way. The rules specifically say not to make comments that are obvious or unimportant. Documentation formatting nitpicks like this don't require code changes and don't impact functionality. The inconsistent capitalization could be confusing to some users, and maintaining consistent formatting is important for professional documentation. While consistency is good, this is too minor to warrant a PR comment. The current format is perfectly understandable and doesn't impact functionality or user experience significantly. Delete this comment as it's too minor and doesn't require a code change. It violates the rule about not making obvious or unimportant comments.
10. docs/content/docs/developer/architecture.mdx:42
- Draft comment:
Typo: In the directory structure, "Nextjs" should be written as "Next.js" for consistency with other mentions. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the inconsistency, the rules state we should not make purely informative comments or obvious changes. This is a minor formatting issue in documentation that doesn't affect functionality. The meaning is clear either way. The inconsistency could potentially confuse readers or make the documentation look less professional. Documentation quality does matter. While documentation quality matters, this is an extremely minor formatting issue that doesn't impact understanding. The rules specifically say not to make obvious or unimportant comments. This comment should be removed as it addresses a trivial formatting issue and doesn't highlight a significant problem that requires attention.
11. docs/content/docs/developer/architecture.mdx:49
- Draft comment:
Typographical error: "Chrome Devtool" should be corrected to "Chrome DevTools". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct that the official name is "Chrome DevTools", this is a very minor documentation issue that doesn't affect understanding. The current spelling is close enough that readers will understand the meaning. Documentation nitpicks like this create noise without adding much value. The official product name is indeed "Chrome DevTools", so there is technical merit to the correction. Documentation accuracy can be important for professionalism. While accuracy is good, this level of nitpicking on documentation creates unnecessary noise in PR reviews. The current spelling doesn't impede understanding. This comment should be removed as it's too minor of an issue and doesn't meaningfully improve the documentation.
12. docs/content/docs/developer/electron-to-web-migration.mdx:35
- Draft comment:
Typographical note: The capitalization for "webview" is inconsistent. In the code block (line 32) it is written as "WebView", but in the description (line 35) it appears as "webview". Consider using a consistent style. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a purely stylistic comment about documentation. It doesn't affect functionality or code quality. The inconsistency is minor and both forms are commonly used - 'WebView' in code contexts and 'webview' in prose is actually a normal pattern. The comment doesn't suggest any meaningful improvement. The inconsistency could potentially confuse readers about whether these are the same thing. Documentation clarity is important. The context makes it very clear these refer to the same thing, and the mixed capitalization (uppercase in code, lowercase in prose) is a common documentation pattern that readers are used to. This comment should be deleted as it's overly pedantic and doesn't improve the documentation's clarity or usefulness.
13. docs/content/docs/developer/running-locally.mdx:48
- Draft comment:
Typo: 'best api' should be 'best API' to maintain consistency in capitalization. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about the capitalization, this is a very minor issue in documentation. The meaning is perfectly clear either way. Documentation nitpicks like this create noise and don't materially improve the codebase. This isn't about code quality or functionality. The consistent use of technical acronyms could be considered part of maintaining professional documentation standards. While consistency is good, this minor capitalization issue doesn't impact readability or understanding, and fixing it provides minimal value compared to the notification noise it creates. Delete this comment as it's too minor of an issue to warrant a PR comment.
14. docs/src/app/layout.config.tsx:16
- Draft comment:
There's an extra space in the element; consider removing the space (i.e., use<span>
instead) for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct, this is an extremely minor formatting issue that doesn't affect functionality. It's purely cosmetic and doesn't impact code quality or maintainability in any meaningful way. This feels like unnecessary nitpicking that adds noise to the review process. The extra space could be considered a minor inconsistency in code style that might propagate if other developers copy this pattern. The impact is so minimal that it doesn't warrant a comment. Most teams would consider this too trivial to mention in a code review. Delete this comment as it's too minor and doesn't meaningfully improve code quality.
Workflow ID: wflow_Y2PBqIdiqhuMesII
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Looks good to me! 👍
Reviewed 005a4f0 in 56 seconds. Click for details.
- Reviewed
49
lines of code in2
files - Skipped
0
files when reviewing. - Skipped posting
5
draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. apps/web/client/src/app/_components/button-link.tsx:7
- Draft comment:
Consider replacing the inline style (width: 'fit-content') with a CSS class for maintainability. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
2. apps/web/client/src/app/_components/button-link.tsx:1
- Draft comment:
Consider adding accessibility attributes (e.g. aria-label) if this ButtonLink is used for interactive navigation, to improve usability for screen readers. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
3. apps/web/client/src/app/page.tsx:5
- Draft comment:
Good refactor: moving the inline ButtonLink definition to a shared component enhances consistency and reuse. - Reason this comment was not posted:
Confidence changes required:0%
<= threshold50%
None
4. apps/web/client/src/app/page.tsx:40
- Draft comment:
The href attribute is using a placeholder ('#'). Ensure to replace it with a valid URL for production. - Reason this comment was not posted:
Confidence changes required:33%
<= threshold50%
None
5. apps/web/client/src/app/page.tsx:1
- Draft comment:
The PR description mentions onboarding docs, but this diff focuses on homepage design changes. Please confirm that documentation updates will follow if intended to resolve issue [FEAT] Add better onboarding docs #123. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
Workflow ID: wflow_TY7SEbnaSs3DWX0M
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
* starting to design homepage * new sections, rotating contributor pic section * new sections, adjust topbar, footer * add contributor section component --------- Co-authored-by: Daniel R Farrell <[email protected]>
Description
Related Issues
Type of Change
Testing
Screenshots (if applicable)
Additional Notes
Important
Design homepage with new components for hero, contributors, and top bar, and structure main page layout.
ButtonLink
component inbutton-link.tsx
for reusable button links.Create
component inhero/create.tsx
for the hero section.ContributorSection
inlanding-page/ContributorSection.tsx
for displaying contributors.GitHubButton
intop-bar/github.tsx
to display GitHub star count.Hero
component inhero/index.tsx
to includeCreate
andContributorSection
.TopBar
intop-bar/index.tsx
to includeGitHubButton
and user navigation.page.tsx
with sections for features, contributors, FAQs, and footer.This description was created by
for 005a4f0. You can customize this summary. It will automatically update as commits are pushed.