-
Notifications
You must be signed in to change notification settings - Fork 63
OU-1389: Style Guide #1089
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
base: main
Are you sure you want to change the base?
OU-1389: Style Guide #1089
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,3 +22,38 @@ This document defines the monitoring-plugin repository style guides. It is a liv | |
|
|
||
| Existing files that predate this styleguide are not required to be renamed immediately. New files and renamed files must conform. Existing | ||
| non-conforming files will be migrated incrementally over time without disrupting CI. | ||
|
|
||
| New rules: | ||
|
|
||
| ### 1. Use function for component definition | ||
|
|
||
| The displayName of a react component is often used in devtools and the like. When defining a component as a `function` it is able to use the function name, but when defining a function as an `arrow function` you need to add an additional `.displayName` to the variable. | ||
|
|
||
| Needing to remember to add a duplicate `.displayName` to an `arrow function` component is extra mental overhead, so we should use `function` definitions instead. | ||
|
|
||
| ### 2. No default exports | ||
|
|
||
| Do not allow default exports from files, instead require each function, variable, etc. to be exported manually | ||
|
|
||
| ### 3. Require Page files to only export react components ending with Page | ||
|
|
||
| With our component structure and the need to export page modules in package.json and use their exported modules in `.patch.json` we should have consistent module exports as well as file names | ||
|
|
||
| ### 4. Avoid Higher-order Components | ||
|
|
||
| Avoid usage of higher order components like `withFallback` and instead prefer manually wrapping components and context/hooks to deliver data | ||
|
|
||
| ### 5. React Prop names | ||
|
|
||
| camelCase for props unless the prop is a React Component in which case it should be PascalCase | ||
|
|
||
| ### 6. `react/self-closing-comp` | ||
|
|
||
| Always self close tags have no children | ||
|
|
||
| Others for consideration: | ||
|
|
||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. separate visualization from data, using hooks or wrapper components around visualization components
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When using Patternfly components consider creating "wrapper" components that our codebase will use which enable easier backporting by maintaining stable UI structure across versions |
||
| - Barrel Files | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am personally not a fan of barrel files as they add a layer of indirection and don't add any functional change to the codebase. I would prefer either using alias's or just having the full path
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fair enough, I think they are also more useful for libraries rather than a consumer app |
||
| - export all things at bottom of file (easy to find what each file exports) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion about it, but I think IDEs can resolve where the export is so it might be just an overhead
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough, I had just seen the pattern online and thought it was interesting to consider |
||
| - Require commit signing | ||
| - Require conventional commits https://www.conventionalcommits.org/en/v1.0.0/ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 |
||
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.
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.
Agree, maybe we should note this as being for unit and component tests
As I work through the dynamic test running and discuss more with @etmurasaki we can define the e2e tests placement later (maybe
/cypress/features/xor/src/features/x/tests)