You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This already works for linear navigation graphs (see NavigationModelLinearNavTest and the tests that refer to setData), but we need to verify the behaviour for nested navigation graphs, there are some commented out tests in NavigationModelNestedNavTest but they'll need to be re-written.
Consider changing the advice about using plain Strings to identify locations... you still can, but when we send data to locations, the data needs to be kept as part of the location class itself eg:
@Serializable
data classProductPage(valproductId:Int) : Location()
If you used plain Strings to identify your locations eg:
"ProductPage"
You'd need to implement some custom protocal to handle data for example "{locationName}|{data}" eg:
"ProductPage|123"
And your UI code would have to parse that (rather than just doing location.productId)
...OK I've considered it 😬 let's just mention that in the docs where we say you can use String to identify locations and gently encourage people not to do that unless they understand the implication and have some good reason, can link them to this issue
The text was updated successfully, but these errors were encountered:
This already works for linear navigation graphs (see
NavigationModelLinearNavTest
and the tests that refer tosetData
), but we need to verify the behaviour for nested navigation graphs, there are some commented out tests in NavigationModelNestedNavTest but they'll need to be re-written.Consider changing the advice about using plain Strings to identify locations... you still can, but when we send data to locations, the data needs to be kept as part of the location class itself eg:
If you used plain Strings to identify your locations eg:
"ProductPage"
You'd need to implement some custom protocal to handle data for example "{locationName}|{data}" eg:
"ProductPage|123"
And your UI code would have to parse that (rather than just doing
location.productId
)...OK I've considered it 😬 let's just mention that in the docs where we say you can use String to identify locations and gently encourage people not to do that unless they understand the implication and have some good reason, can link them to this issue
The text was updated successfully, but these errors were encountered: