I wouldn't call this "forcing" immutability. It is easier to grok, easier to follow, easier to debug, and easier to test. It follows separation of concerns and limits shared state to only the points of integration.
You did refactor the entire thing. If the point you were trying to make was about immutability, I didn't get it. Using tecniques to make your data immutable in a messy code, still leaves you with a messy code.
If this was about separation of concerns and code organization, you should have said it from the beginning, I would have agreed with you.
The getStateWithNewWord() function gets your new state without mutating it and without calling 3 separate functions to update the state. It is much easier to see how the state is changing this way. That was the main point. Instead of 7 state mutations, it mostly happens in one place.
You're right, simply refactoring the state mutations into a single function left the code messy, hence the larger refactor. Separation of concerns goes hand in hand with techniques like immutability because it keeps the state change where it belongs.
I didn't mean to come off as negative in any way so apologies if it seems that way.
Your original question was whether your code is "procedural". I'd say it would be considered "spaghetti" due to the lack of separation of concerns.
I assumed the question was due to the negative connotation around procedural code. My refactor is procedural but I don't necessarily consider that a bad thing. It still follows good programming practice and gets the job done.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You did refactor the entire thing. If the point you were trying to make was about immutability, I didn't get it. Using tecniques to make your data immutable in a messy code, still leaves you with a messy code.
If this was about separation of concerns and code organization, you should have said it from the beginning, I would have agreed with you.
The
getStateWithNewWord()function gets your new state without mutating it and without calling 3 separate functions to update the state. It is much easier to see how the state is changing this way. That was the main point. Instead of 7 state mutations, it mostly happens in one place.You're right, simply refactoring the state mutations into a single function left the code messy, hence the larger refactor. Separation of concerns goes hand in hand with techniques like immutability because it keeps the state change where it belongs.
I didn't mean to come off as negative in any way so apologies if it seems that way.
Your original question was whether your code is "procedural". I'd say it would be considered "spaghetti" due to the lack of separation of concerns.
I assumed the question was due to the negative connotation around procedural code. My refactor is procedural but I don't necessarily consider that a bad thing. It still follows good programming practice and gets the job done.