I choose approach depending on required name. For ...

# announcements

[gildor]

I choose approach depending on required name. For your example with state, because you already have suffix “State” everywhere, I would choose first one. But it’s not always necessary

[ursus]

Well I like the nesting declaration of the first one, but callsitea of State.Enabled.Staging.Pending feels weird

[ursus]

But also PendingState would loose to much info, not sure..

[gildor]

State.Enabled.Staging.Pending is definitely huge overkill imo

[gildor]

Why not State.Pending?

[gildor]

again, it depends of course, don’t think that there is unversal rule

[ursus]

Well its a subsubsubstate, you can have more levels of nesting, thats where im not sure on naming

[ursus]

thats was just an one concrete state example out of the tree, ofc its not just nested for sake of nesting

[ursus]

@Ruckus why do you think so? I mean that is proper modeling of the problem I think, for example from my app

State {
	Disabled
	Enabled {
		Idle
		MenuShowing
		Staging {
			Idle
			Gallery {
				NoPermission
                Ready {
				    Pending {
						FromPicker
						FromCamera
				    }
                }
			}
			Gifs
		}
	}
}

[ursus]

little bit pseudocode-y but theyre all disjoint so "model states so invalid states are unrepresentable"

[ursus]

well those exact implied values I thought were to be removed with sealed classes with them being complete

[ursus]

i.e. null being disabled etc, why not model it? State is Enabled I think is mroe expressive than != Disabled, with other values being on the same semantic level; but yes its semantics

[ursus]

btw I dont see how abstract hierarchies give you more flexibility? You mean like extending to "enum" in some subclass somewhere else? Other than that, if the domain changes you need to make changes anyways

[gildor]

I think all hierarchy of Ready is overkill, why not just Ready state with some data?

[ursus]

yea it has some data to it, it ommited that, sry

[gildor]

Also not sure about Disabled state. Why not just move it to the same level as Enabled.Idle and get rid of Enabled and Disabled level, also if you get rid of Ready you will get:

Disabled
Idle
MenuShowing
Staging {
    Idle
    Gallery {
      NoPermission
      Ready(some, data)
    }
    Gifs
}

And probly next step would be just get rid of “Staging” And probably gallery (but it depends, do you have or not addfitional nexted cases), and get completely flat states:

Disabled
Idle
MenuShowing
StagingIdle
NoPermission
Ready(some, data)
Gifs

[gildor]

Actual implementation of course depends on your case and how you separate your code (probably you want to pass state), but also if you want separate different parts of UI to have own substates, I’m not sure that it should be one huge sealed class, instead some additional sealed class for particular use case

[ursus]

well technically youre not wrong, since you basically picked out all non abstract classes (leaves), but, what is the gain? isnt the nestedness of the hierarchy actually semantically helpful? All states that have the { } in the pseudocode are abstract

[ursus]

with abstract classes havign some sort of common property for its subclasses etc., guess I should have posted the actual code sorry

[ursus]

Disabled
Enabled {
	abstract val text

	Idle
	MenuShowing
	Staging {
		abstract val stagedItems

    	JustItems
    	GalleryPicker {
			NoPermission
			Ready(some, data)
    	}
    	GifsPicker {
    		NoInternet
    		Ready(some, data)
    	}
	}
}

[ursus]

would this change something in your mind?

[gildor]

I still don’t understatnd why I need Disabled/Enabled

[gildor]

Staging probably fine, but I would just have one more sealed class for UI that manages this state

[ursus]

Well, its model for the "bottom part" of a chat ui, think like slack, where you can show the menu, gallery etc, and Disabled is when you dont have a business permission to post to given channel

[gildor]

I mean disabled is fine, But I would just inline it and have on the same level as Idle

[ursus]

And I wanted to model it all together because its disjoint, i.e. Disabled should overwrite any current state, so I figured state = Disabled is better then, stagingState = null, whateverState = null, etc

[ursus]

well, all Enabled states have text (current text input)

[gildor]

Noi need to use null, I’m talking about structure of your states and Enabled/Disabled seems just wrong nesting

[gildor]

Even “Idle”?

[ursus]

Yes sorry I replied to your 'staging' mistake message

[gildor]

again, you now arguing by showing some additional info about your case, of course I can say only about what you already shared

[ursus]

Idle is when nothing else is showing, just text bar

[gildor]

Your original question was “how to handle this”, as I said, it up to your case, but what you showing looks incorrect for me as misuse of this approach IMO even if from puristic point of MVI is correct

[ursus]

Im not saying youre wrong, I appreciate the feedback, I just dont see why you want to put Idle and Disabled on same level, as Idle is Enabled which gives it val text

[gildor]

And I would rather have a few null fields than having such bloated states structure

[gildor]

Because of this small thing you make your states strucutre unnecessary complicated imo

[gildor]

so I would just remove text from enabled state

[gildor]

and enabled state too

[gildor]

you also can have just some interface implemented by those states that provide text to just avoid this nesting

[ursus]

but then in view you cannot do when state is Enabled then editText.text = state.text, but rather case for each branch, duplicating code

[gildor]

and if one day you will need text on disabled state (which perfectly possible for me) all your structure become useless and will be refactored

[ursus]

well, if world changes, model changes, why is that a problem

[gildor]

interface StateProvider {
   val text: String
}
editText.text = (state as? StateProvider)?.text

[gildor]

Because you have to change it because of very small feature and you bloated struture of models because of this

[ursus]

how is it bloated, its just inheritance hierarchy

[gildor]

As I said, because Enabled/Disabled as top level state looks unnecessary for me, they do not solve any significant problem

[ursus]

one carries data, other does not, and you solved it via interface, which would be the only super class so..I dont see how is it better, but thank you anyways, I need feedback

[ursus]

btw my original question basically was if, style-wise should one nest substates in parent state (classes), or all top level + postfix

[gildor]

With such structure every style looks bad imo, with prefix or with nesting