What do you guys think about adding some compose i...

# compose

[Cicero]

What do you guys think about adding some compose into your data models? 🤔

[Cicero]

Some times I have an idea and I try to force it to work, lucky me this one wasn't such problem and it came out kind of interesting:

sealed class FitnessRowItem : FitnessItem {
    data class TrainingRowItem(
        override val isFavorite: Boolean,
        val trainingName: String,
        private val durationInMinutes: Int,
        override val exerciseImplModels: List<ExerciseImpl.Model>,
        override val id: Int,
        ) : FitnessRowItem() {
        override val width: Float = 0.8f
        override val footerHeight: Float = 1.2f

        @Composable
        @ReadOnlyComposable
        fun durationDescription(): String {
            val hours = durationInMinutes / 60
            val minutes = durationInMinutes % 60
            return if (hours > 0) {
                "$hours:$minutes $minutesLocalizedShort"
            } else {
                "$minutes $minutesLocalized"
            }
        }

        private val minutesLocalizedShort: String
            @Composable
            @ReadOnlyComposable
            get() = stringResource(id = R.string.pager_item_minutes_short)
        private val minutesLocalized: String
            @Composable
            @ReadOnlyComposable
            get() = stringResource(id = R.string.pager_item_minutes)
    }

    data class ExerciseRowItem(
        override val isFavorite: Boolean,
        override val exerciseImplModels: List<ExerciseImpl.Model>,
        override val id: Int = exerciseImplModels.first().id,
        ) : FitnessRowItem() {
        override val width: Float = 0.4f
        override val footerHeight: Float = 0.4f
    }
}

[Michael Paus]

Compose, or any other GUI stuff, is a no go in the model part!

[adjpd]

What are you trying to do with your code? It's unclear to me.

I've only used Compose to do UI, but I hear it could be useful elsewhere, since it's essentially, I believe, the composition of a tree data structure.

[Cicero]

It's not about if it should or not go into a model.

The FitnessRowItem is the already beyong the general model that will be used in my application, it is a slice o the FitnessModel.

This model is shaped into something that will be presented inside of rows that are identical troghout the app.

There is a FitnessModel and this is my FitnessRowModel, the stuff rows should be presenting.

If you look inside of it, the composable uses information from the FitnessRowItems that I would be passing as parameters if they were separated. This two things are going to be, absolutely, always, the combination of compose and data.

My objective was to try something different and experiment with it, feel how this fit or not in my system and if it brought problems related to maintenance and etc.

[Cicero]

I would appreciate more than "you shouldn't do it". I know about the single responsability principles. I know why I shouldn't be doing this.

But I was experimenting on the level of, does this improves the usability of my system? Does this improves general understanding and precision?

The answers of this questions are personal and I would like to feel why you would want to work in a code base like this for example.


This is something very specific. It is my only data model that carries a UI representation because of its use case.

I hope this grains of salt improve the discussion.

[Michael Paus]

Well, I am coming here from a JavaFX background and JavaFX uses properties and binding to connect the GUI with the model. Just right now I am going through the hell of having to deal with models which have all these dreadful (JavaFX specific) properties in them which I cannot reasonably use in a Compose context. That’s why I want to keep all my models free of all GUI related stuff in the future. I hope this explains my statement better although I think that you may be at a border line between the real model and some GUI specific data but I am not sure.

[Adam Powell]

yeah ideally these composable methods should work just as well as top-level composable functions that accept the data model type as a parameter

[Adam Powell]

this forces you to provide public read access to any data the (now external) composable function reads

[Adam Powell]

which will then make the original object easier to factor, maintain, use and test in general