:sweat_smile: I like the coincidence, as I already...
# naming
j
😅 I like the coincidence, as I already had a naming question today. We currently try to split up our composables into container (with viewmodel) and stateless view. In this example the container is suffixed with
Route
- which I do not like. I also do not like to suffix the view with
View
- as this term is really overloaded on Android. Any suggestions?
1
l
I do like https://bradfrost.com/blog/post/atomic-web-design/ I feel it fits nice declarative ui. Where Page/Screen is the real thing that takes in view model dependency. And Template that is reusable screen component you pass state from view model / preview / instrumentation tests, etc....
j
@Liudas Survila thx for the response. That makes the question even more complex as we have our own library with the atomic design templates we then use in the view. 😉 Means: we reuse atomic design templates on multiple screens/views.
s
So what is it that makes the “Route” suffix not work for your case? If your app is structured where each destination is a screen, and you can refer to it as a “route” it feels quite fitting and I wouldn’t try to give it a new name. What makes you dislike the “Route” suffix by itself?
j
We settled on the route suffix after an internal discussion. Thx again for the inputs.
p
Route sounds good, I believe there is another navigation Library named "Conductor" that uses Route too. I use Node suffix that contains a ScreenX. Each ScreenX receives its own ScreenXState.