Taking a peak at `NavigationSuiteScaffold` and how...

# compose-android

[Jonathan]

Taking a peak at NavigationSuiteScaffold and how it works internally, I noticed an interesting design choice of NavigationSuiteType. It’s a value class that wraps an String. Seems like this class is enum-like and represent well-known values (NavigationBar, NavigationRail, NavigationDrawer, None) at compile time. Does anyone have insights of this design decision? Why use a value class in this manner over an enum or even a sealed class? Is there a performance benefit to be had using a value class?

[Alex Vanyo]

It all has to do with library compatibility.

If a library ships an enum class or a sealed class, then a consumer can expect to use an exhaustive when to enumerate over all cases.

That can be nice - but it leads to problems if the library wants to add another case in a future version. Adding a case to the enum class or a sealed class in the library would then break any consumer, since that consumer now needs to handle the new case in source, and otherwise fail to compile or crash at runtime. Since its a breaking change, those generally need a major version bump to the library to comply with semantic versioning, which is super disruptive.

The value class setup with an entirely internal identifier is commonly used in Compose libraries for these enum-like things that might expand in the future

[Jonathan]

Thanks for the explanation… If it was performance benefit I was going to next ask why not wrap an Int instead of a String.