Status Update
No update yet.
Comments
di...@google.com
Polina, it seems we might be considering varargs as mandatory here? Regarding the second remeber issue, that should be fixed in the next canary.
ko...@google.com
an...@google.com
an...@google.com
As mentioned in
Now, the behavior for autocomplete on val state = rememberSa will be to fill in:
val state = rememberSaveable {
<caret>
}
The similar scenario for remember is also fixed.
Regarding overload order: that behavior is coming from the IntelliJ platform and is based on a number of factors. In fact, there are times in my testing that the order has been swapped from what was suggested, likely due to my having chosen the other option more frequently. Absent a strong rationale for diverging from the platform, I've left that to default to current behavior.
Description
Build #AI-203.7148.57.2031.7185775, built on March 5, 2021
Runtime version: 11.0.8+10-b944.6842174 x86_64
VM: OpenJDK 64-Bit Server VM by N/A
macOS 10.15.7
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 16
Registry: external.system.auto.import.disabled=true
compose_version = '1.0.0-beta02'
When I write a compose code I start writing
val state = rememberSa
1) I see that the second suggestion by studio is correct so I choose it and tap enter. The autocompletion add this code:
val state = rememberSaveable(inputs = CURSOR_IS_HERE, init = { /*TODO*/ })
Which is unreasonable as
a) specifying inputs are optional they are defined as vararg.
b) I would never use init = {} syntax for a last lambda param as I can use trailing lambda syntax
So autocomplete I consider as a correct one is
val state = rememberSaveable { CURSOR_IS_HERE }
2) There are two overloads:
a) fun <T : Any> rememberSaveable(
vararg inputs: Any?,
saver: Saver<T, out Any> = autoSaver(),
key: String? = null,
init: () -> T
): T
b) fun <T> rememberSaveable(
vararg inputs: Any?,
stateSaver: Saver<T, out Any>,
key: String? = null,
init: () -> MutableState<T>
): MutableState<T>
I don't see the reasons why the overload b) is suggested first. It requires more non-optional params as is needed for the more advances use cases. It would be great to first suggest overloads which require less params to provide if it is possible.
3) I think similar issue happens with just a regular remember {} funciton
I start typing
val state = reme
I see that the most generic remember overload is the second one in suggestions, I choose it and tap enter. I got this:
val state = remember(calculation = { /*TODO*/ })
Which is unreasonable in the same way as everyone would use the trailing lambda syntax so I expect such autocomplete instead:
val state = remember { CURSOR_IS_HERE }