Conversation
🟢 Netlify deploy for commit ee5b9b3 succeededDeploy preview: https://69b1a73f31e42e8d6c77f468--ouds-android.netlify.app |
578357d to
ee5b9b3
Compare
| 2. **Compose Best Practices**: Use modern Jetpack Compose patterns | ||
| 1. **Coding Conventions**: Follow [Style guidelines for Jetpack Compose APIs](https://developer.android.com/develop/ui/compose/api-guidelines) which basically includes: | ||
| - The [API Guidelines for Jetpack Compose](https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-api-guidelines.md) (based on [Kotlin Coding Conventions](https://kotlinlang.org/docs/coding-conventions.html)) | ||
| - The [API Guidelines for @Composable components in Jetpack Compose](https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-component-api-guidelines.md) | ||
| 3. **Naming**: | ||
| - Prefix components with `Ouds` (e.g., `OudsTag`, `OudsButton`) | ||
| - Token classes end with `Tokens` (e.g., `OudsAlertTokens`) |
|
|
||
| When adding new components: | ||
|
|
||
| 1. Verify that component tokens generated by Tokenator are defined in `:theme-contract` and implemented in theme modules (`:theme-orange`, etc.) |
There was a problem hiding this comment.
Tokenator is mentioned twice in the file but there is no explanation of what it is.
| 2. Create one or more composables in `:core` module, trying to match the equivalent Material APIs as much as possible | ||
| 3. Ensure accessibility semantics are properly implemented | ||
| 4. Add a sample code for each component composable | ||
| 5. Include `@Preview` annotations for IDE preview |
There was a problem hiding this comment.
Do we have to explain how a Preview should be written in the project, with the use of OudsPreview and AppPreview?
| Demo screens use state classes (e.g., `AlertMessageDemoState`, `InlineAlertDemoState`) to: | ||
| - Manage component configuration | ||
| - Provide interactive controls in demo app | ||
| - Showcase different component variants |
There was a problem hiding this comment.
Maybe we can add something about the support of configuration changes (use of Saver)?
| When adding new components: | ||
|
|
||
| 1. Verify that component tokens generated by Tokenator are defined in `:theme-contract` and implemented in theme modules (`:theme-orange`, etc.) | ||
| 2. Create one or more composables in `:core` module, trying to match the equivalent Material APIs as much as possible |
There was a problem hiding this comment.
| 2. Create one or more composables in `:core` module, trying to match the equivalent Material APIs as much as possible | |
| 2. Create one or more composables in `:core` module, trying to match the equivalent Material 3 APIs as much as possible |
| - Ensure proper semantic roles | ||
| - Support TalkBack and other accessibility services | ||
| - Maintain sufficient color contrast | ||
|
|
There was a problem hiding this comment.
Suggestion from Gemini: "Any hardcoded string must be avoided; use stringResource."
| 6. Add snapshot tests in `:core-test` module and generate snapshots for each theme | ||
| 7. Add instrumented Compose UI tests for user interactions such as clicks | ||
| 8. Add demo screen in `:app` module | ||
|
|
There was a problem hiding this comment.
I think that something is missing: add the new component in Component.kt file of :buildSrc.
Do we have to precise that components must be documented in a specific format with the design guideline link and the design version?
|
|
||
| ## Contributing | ||
|
|
||
| See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed contribution guidelines. |
There was a problem hiding this comment.
I think we have to update the CONTRIBUTING.md because it doesn't seems to be up-to-date.
No description provided.