-
Notifications
You must be signed in to change notification settings - Fork 8
Ci test #43
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
Conversation
Lint reportResults
Suppressed ResultsNothing here. Rules informationRules details, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , See https://mrmans0n.github.io/compose-rules/rules/#naming-composable-annotations-properly for more information. See https://mrmans0n.github.io/compose-rules/rules/#compositionlocals for more information. See https://mrmans0n.github.io/compose-rules/rules/#naming-compositionlocals-properly for more information. If a composable should offer additional control surfaces to its caller, those control surfaces or callbacks should be provided as parameters to the composable function by the caller. You can wrap the slot in a remember { movableContentOf { ... }} block to make sure their internal state is preserved correctly. See https://mrmans0n.github.io/compose-rules/rules/#slots-for-main-content-should-be-the-trailing-lambda for more information. , Composable functions that emit content usually reserve the trailing lambda syntax for the content slot, and that can lead to an assumption that other composables can be used in that lambda. If restarting the effect is ok, you can add the reference to this parameter as a key in that effect, so when the parameter changes, a new effect is created. See https://mrmans0n.github.io/compose-rules/rules/#dont-use-material-2 for more information. See https://mrmans0n.github.io/compose-rules/rules/#modifier-order-matters for more information. You should consider migrating this modifier to be based on Modifier.Node instead. See https://mrmans0n.github.io/compose-rules/rules/#when-should-i-expose-modifier-parameters for more information. See https://mrmans0n.github.io/compose-rules/rules/#naming-modifiers-properly for more information. You should move the modifier usage to the appropriate parent Composable. Use Modifier (with a capital 'M') to construct a new Modifier that you can pass to other composables. See https://mrmans0n.github.io/compose-rules/rules/#modifiers-should-have-default-parameters for more information. See https://mrmans0n.github.io/compose-rules/rules/#do-not-emit-multiple-pieces-of-content for more information. Mutable objects that are not observable, such as ArrayList or a mutable data class, cannot be observed by Compose to trigger recomposition when they change. , If possible, consider making the component stateless and concede the state change to the caller. If mutation of the parent’s owned property is required in the component, consider creating a ComponentState class with the domain specific meaningful field that is backed by mutableStateOf(). However, Composable functions that return a value should start with a lowercase letter instead. They should follow the standard Kotlin Coding Conventions for the naming of functions for any function annotated @composable that returns a value other than Unit Examples: , , , See https://mrmans0n.github.io/compose-rules/rules/#preview-composables-should-not-be-public for more information. , If you don't remember the state instance, a new state instance will be created when the function is recomposed. You should use Kotlinx Immutable Collections instead, or create an See https://mrmans0n.github.io/compose-rules/rules/#avoid-using-unstable-collections for more information. See https://mrmans0n.github.io/compose-rules/rules/#hoist-all-the-things for more information. Acquiring a ViewModel should be done in composable default parameters, so that it is more testable and flexible. Tool information
|
No description provided.