`2.0.0-beta.1` migration documentation `LineCartesianLayer.rememberPoint` not found

[mak1nt0sh]

Area

Maybe it should be rememberPoint -> LineCartesianLayer.point?

I also see it is no longer remembered?

Error

Unresolved reference: LineCartesianLayer.rememberPoint

Additional information

No response

[patrickmichalik]

Hello! Thanks for the report. The replacement API is, indeed, LineCartesianLayer.point. We’ve corrected the release notes and will get back to you as soon as we can to describe the reason why the new function doesn’t use remember.

[patrickmichalik]

Generally, remember should be used in these cases:

1. when the same instance of a class must be retained across recompositions for functional reasons (consider, for example, VicoScrollState)
2. for heavy calculations that needn’t be performed on each recomposition

Previously, some of the compose module’s factory functions used remember when neither of these conditions was met. This did the following:

• It created redundancy.
• It needlessly made some factory functions composable, increasing the number of cases where two factory functions were required for the same API—one for composable contexts, and one for ExtraStore lambdas and the like.
• It led to inconsistency with those factory functions where remember was unneeded and thus, as expected, not used.

Vico 2.0.0 Beta 1 addresses this excessive use of remember, among other things, hence the dropping of remember for LineCartesianLayer.Point. It’s clear that condition 1 isn’t met. As for condition 2, LineCartesianLayer.Point is only a light data carrier—instantiating it doesn’t constitute a heavy operation. (It does require a small amount of processing, of course, but so does retrieving a value saved by remember.)

In strong skipping mode, the use of remember for objects of unstable types facilitates composable skipping. Some of the factory functions from which remember was removed in Vico 2.0.0 Beta 1 return such objects. There’s no regression here, however, as Vico uses strong skipping mode only since the same version. (It’s on by default in Kotlin 2.0.20 and later.) Regardless, skipping will be made possible in all these cases—and many more—but by means of marking these APIs as stable or immutable, which is more appropriate here. We’ve been working toward this since version 2.0.0 Alpha 23, and version 2.0.0 Beta 2 will include significant advancements in this respect.