docs: update CONTRIBUTING_JS.md #784
Conversation
add some more details to align with unknown expectations that I've seen from contributors lately. i.e. ipfs/ipfs-webui#2349
There was a problem hiding this comment.
Pull Request Overview
This PR updates CONTRIBUTING_JS.md to provide additional guidelines for contributors on file naming, TypeScript usage, and front-end/UI practices.
- Added a "Files" section addressing TypeScript and case-sensitivity for filenames.
- Introduced a section on importing modules with file extensions to comply with ESM.
- Added front-end guidelines for React projects, including component naming and file extension recommendations.
Comments suppressed due to low confidence (1)
CONTRIBUTING_JS.md:170
- [nitpick] Clarify the rationale for using kebab-case for React components as it deviates from the common practice of using PascalCase. Providing context will help avoid confusion for contributors accustomed to standard React naming conventions.
1. Component Naming: Use kebab-case for component names (e.g., `my-component`). This is different than idiomatic React, which uses PascalCase.
|
|
||
| 1. Component Naming: Use kebab-case for component names (e.g., `my-component`). This is different than idiomatic React, which uses PascalCase. | ||
| 2. File Extensions: Use .tsx for files containing React components to leverage TypeScript's JSX support. | ||
| 3. State Management: Prefer using React's built-in state management features. If additional state management libraries are needed, please ensure they are well-justified, align with the project's architecture, and are well-typed. |
There was a problem hiding this comment.
| 3. State Management: Prefer using React's built-in state management features. If additional state management libraries are needed, please ensure they are well-justified, align with the project's architecture, and are well-typed. | |
| 3. State Management: Prefer using React's built-in state management features. If additional state management libraries are needed, please ensure they are well-justified, align with the project's architecture, and are well-typed. (e.g. do not use redux-bundler) | |
| 4. Do not use prop-types or `.defaultProps` | |
| 5. Use functional components, hooks, and context where appropriate. Classes may be used for the logic of your components, but the component itself should be functional. |
There was a problem hiding this comment.
@achingbrain any thoughts on these additions?
There was a problem hiding this comment.
I don't have any strong preferences around react/redux/etc. I don't use it much and every time I do, it seems to have changed completely so happy to go with whatever.
Co-authored-by: Alex Potsides <[email protected]>
Co-authored-by: Alex Potsides <[email protected]>
Co-authored-by: Alex Potsides <[email protected]>
|
|
||
| `aegir` can help you set up a new project with an appropriate tsconfig.json. | ||
|
|
||
| ##### Case-sensitivity |
There was a problem hiding this comment.
Maybe make a note that this is a recommendation and that at the very least it's important to maintain consistency on a project level. Because currently not all projects use kebab-case.
For example https://github.com/ipfs/ipld-explorer-components/tree/master/src/components uses PascalCase.
|
|
||
| 1. Component Naming: Use kebab-case for component names (e.g., `my-component`). This is different than idiomatic React, which uses PascalCase. | ||
| 2. File Extensions: Use .tsx for files containing React components to leverage TypeScript's JSX support. | ||
| 3. State Management: Prefer using React's built-in state management features. If additional state management libraries are needed, please ensure they are well-justified, align with the project's architecture, and are well-typed. |
There was a problem hiding this comment.
I agree redux-bundler proved to be a flop. Either way, I wouldn't prescribe this on an org level. Instead I'd leave it up to the maintainer of the specific library.
There was a problem hiding this comment.
We should advise against redux-bundler at the org level because it breaks type-safety.
add some more details to align with unknown expectations that I've seen from contributors lately.
i.e. ipfs/ipfs-webui#2349