Much too long a method?

I finally have my initial project to the point that it appears to run, is properly formatted, and passes clippy without complains. And I got enough help to put it up on github. Which gets to the quesiton I am now asking.
In Rolodex/src/rolo_window/person_gui.rs at main · JoelHalpern/Rolodex · GitHub there is a person_update function, called from my main iced update function. It is so long as to be hard for me to understand, and I know what it is doing. I could take the longest part out into a separate function, but it would still be a monster. Am I doing something fundamentally wrong, is there a technique I am missing, or is this just what happens with iced update methods?
Thanks,
Joel

Sometimes you just do need a big enum and a big match to go with it.

I would say that it is likely worth splitting out the more complex arms into their own functions, even when this doesn't make the match nicely short. That way, you can separate the mental tasks "read/edit a big match" and "read/edit a nontrivial algorithm".

1 Like

Thanks for the prompt and clear reply. That is what I suspected.

I was about to say word for word what kpreid said.

It's typical for theupdate method to get large, in iced apps, but it is simply one big match statement, so don't worry about that, in and of itself.

You could organize you PeopleMessage enum, it is kind of long and some of the discriminates are groupable. I didn't study it much, but it looks like some are meta? (PeopleButtonPressed, UseActivePeople, UseArchivePeople), some edit people (EditPerson, NameEntry, etc), some modify the list of people and some do search.

Some of the discriminates could have sub-enums.

Thanks for teh detailed reply. I think I now see how I could factor out another set of messages.