Skip to content
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

Add page from Builder #2192

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Add page from Builder #2192

wants to merge 1 commit into from

Conversation

Aiden-Brine
Copy link
Contributor

@Aiden-Brine Aiden-Brine commented Dec 3, 2024

This draft PR includes a page generated using builder.io based on this design.

Custom Prompts Used

  • If a frame in Figma has the styling display: flex with a gap value, when generating code use a div to represent the frame and provide spacing between the objects in that div equivalent to the gap value.
  • Only provide values to props on components from @jobber/components if they are valid values for those props
  • Only provide props to components from @jobber/components if they are valid props for those components. Do not provide the prop classNames or onChange to any components from @jobber/components.The page component from @jobber/components renders a header so the addition of a header with the same value as the title passed to Page is not necessary.
  • Do not add any styles, HTML divs or colors that were not specified in Figma
  • Do not use position absolute in the CSS
  • Avoid deeply nesting HTML divs and instead break things up into smaller pieces
  • Please wrap all buttons in divs with a display of block
  • Avoid setting a fixed width for items in CSS where at all possible
  • Make sure the code is responsive.

Prompts from builder.io that are editable

Follow these fundamental principles when generating code:

Code Quality:
• Write clean, maintainable, and concise code
• Follow DRY (Don't Repeat Yourself) principles
• Ensure proper error handling

Documentation:
• Add meaningful comments for complex logic
• Document any assumptions or limitations

Naming Conventions:
• Use descriptive and consistent naming
• Follow language-specific conventions
• Avoid abbreviations unless widely recognized

Implement WCAG-compliant, accessible code following these essential requirements:

Semantic Structure:
• Use semantic HTML elements (nav, main, article, section)
• Create logical heading hierarchy (h1-h6)
• Implement proper landmark regions

Interactive Elements:
• Ensure keyboard navigation support
• Maintain visible focus indicators
• Implement proper focus management
• Support touch and mouse interactions

ARIA Implementation:
• Add appropriate ARIA landmarks
• Include descriptive ARIA labels
• Use ARIA states and properties correctly
• Implement ARIA live regions for dynamic content

Media and Content:
• Provide descriptive alt text for images
• Ensure proper color contrast ratios
• Support text resizing and zoom
• Include captions and transcripts for media

Testing Requirements:
• Verify screen reader compatibility
• Test with keyboard-only navigation
• Ensure functionality at 200% zoom

Testing

You can take a look at the page here

Styles mappings

Currently waiting to hear back from their team about doing the styling mappings as there is a gap in their docs about it


In Atlantis we use Github's built in pull request reviews.

Random photo of Atlantis

Copy link

github-actions bot commented Dec 3, 2024

⚠️ Pull Request titles in this repo follow the Conventional Commits specification.

No release type found in pull request title "Add page from Builder". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit

@Aiden-Brine
Copy link
Contributor Author

The responsiveness certainly leaves something to be desired

Screenshot 2024-12-02 at 5 27 06 PM

/>

<InputText
align="left"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This and the value for size are invalid. I have it set up so it should be mapping to correct values, I need to talk to their team about that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay I figured out what was going on with this one and it is now correctly mapping

<InputFile
allowedTypes="all"
variation="dropzone"
className={styles.fileInput}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is still adding className and onChange even though I am explicitly telling it not to

}) => (
<div className={styles.securityBlurb}>
<Icon name="lock" size="small" className={styles.securityIcon} />
<div className={styles.securityText}>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

huh, styles.securityText just straight up doesn't exist 😬

variation="dropzone"
className={styles.fileInput}
allowMultiple
onChange={setFiles}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Input file requires a getUploadParams prop. There is no equivalent in Figma but I added it to the mapping file so I would expect it to be added here. I am waiting to hear back from their team on that

Copy link
Contributor

Choose a reason for hiding this comment

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

there are a handful of styles that I'm pretty skeptical of. they either do nothing, or are a questionable way of achieving the desired result.

one example is the .container class having equal padding AND justify-content/align-items center. those are both doing the same thing, trying to center the content except only the padding is doing what it is supposed to do since the container has no provided dimensions to center its content within.

at first glance this seems reasonable making it easy to miss and leave behind some code that is not needed. also, we can't ask the "author" what they were going for.

Copy link
Contributor

Choose a reason for hiding this comment

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

it's also oddly inconsistent with what it solves a problem with

in the .container it used display: flex to fill the width, which is valid.

then in a handful of other classes it used width:100% to do the same thing, which is once again superfluous since it's applying that to a div which has display: block. the rule isn't providing the wrong behavior it's just that you don't need to even apply that rule for it to do the right thing.

Copy link
Contributor Author

@Aiden-Brine Aiden-Brine Dec 3, 2024

Choose a reason for hiding this comment

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

Great callout! I also have some concerns about unnecessary CSS. It currently has no awareness of our components so I have seen it wrapping components with a size prop in a div specifying what the size should be. Potentially fixable by telling the AI "if you encounter a component with a size prop don't use CSS to control its size". This is brittle for two reasons:

  • If a component comes along where a prop other than "size" controls its size
  • More likely a component has a default size value so there is no size prop provided. InputText for example takes a size prop of "small" | "large" and if none are provided it uses the value of "base" (arguably bad design not allowing the default value as a prop but that is the current situation). If no size prop is provided it will assume it needs to wrap it in a div and add its own CSS to size it.

This isn't an issue right now because it isn't noticeable but I see this becoming a problem if we want to change the size in the future. The developer will change the size prop and be confused about why it isn't working. Turns out there is also CSS now dictating the wrong size built in

<div className={styles.securityBlurb}>
<Icon name="lock" size="small" className={styles.securityIcon} />
<div className={styles.securityText}>
Documents and files you upload are stored securely as per our{" "}
Copy link
Contributor

Choose a reason for hiding this comment

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

a couple things here

  • first it's putting text directly in a div rather than some kind of text element which I don't love
  • second, the {" "} is an interesting way to add a space. I get that a formatter might remove a trailing whitespace but still. I don't love it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants