 So like I said in the video where I covered Settings or configurations and why they are the root of all evil basically why why they Can cause complexity to spiral out of control I did say that there was a tool I had Available to me that helped me tackle this because all of this was unfortunately justified most of the time Most of the time various settings and stuff stuff are added because Somebody can't figure out a sane default a team can't agree on how something should work And those types of settings are things that absolutely should be avoided due to your research It'll actually wind up saving you quite a bit of money because that research is going to cost way less than maintaining the additional complexity, but There are inevitably real cases of extreme complexity and You need tools to deal with that. So what I've added to this is Not the full Thing that I've done, but it is enough to demonstrate My approach to this This will not apply unilaterally to every single situation where you have tons of different settings It's just what worked in my specific case so I Had an original implementation that was not very good And then after it spiraled out of control into a little with 16 settings at that point We added three more later that were much easier to add, but You know a severe level of complexity and I'm like, alright, I need to refactor this I need to rewrite a huge portion of Of this work I did Which is not something to be feared guys It's not actually that bad and it saved me quite a bit of headaches in the long run So looking at this the different settings are I called them flags in my implementation, but it essentially What I realized is these things Decided the state of the menu and the menu was essentially a record just as a record that What was in it shifted around Now in many languages, there isn't a concept of a variant record. So how can we do this? well In many languages, especially when you get to the more functional side of things They don't really have structures. They tend to do everything through tuples and lists I can make a list of menu items and then just use Some control logic to decide what actually goes in and what doesn't the flags the settings decide state and We have what is conceptually a variant record. So it's sort of this come at least And this is what I really mean by specific solutions to specific problems. This is Not something that's going to work for say You're trying to model an oven that this would be a terrible approach to that You don't need any type of variant record Concept with that at all and this is as it turns out this solution actually worked better than a pure variant record would like I'm not sure if any other lane of any other languages that have it But they variant record as it exists in Ida would not be actually be good for this, but it's This obviously isn't such a simple state machine is that you can use a dictionary list Because or an associative array because you have quite a bit of interaction between these settings In some cases they turn something off for just a period of time and then it needs to revert back to where it was in the first place Some people might think oh well you can use a monad for that and then look up go back to the previous monad Which works assuming nothing else was changed So there's quite a bit of interaction between these More or less how this works You have a menu item like you would expect with the price in the name These were just so that I could print the stuff out the entire menu out pretty easily But then I've intimately did it just as a list along with some control logic now This is essentially a combination of token driven and event driven the build procedure or We forget exactly how that worked in JavaScript. I haven't looked at my stuff recently, but It's essentially an event. See I this isn't a Any type of concurrent process going on so It's not like an actual It's not like an actual event or rendezvous would need to be sent off It just needs to be told when to rebuild and this was sort of an optimization because in a token driven state machine Every single time a new setting was set to sent to it It would change its state It would rebuild the entire thing based on Because this is the state for this thing is the actual variant record I would rebuild it for every single setting change. That's not the most efficient when you were sending off multiple multiple Setting changes at once. This is why it's sort of a combination of the two that the the setting multiple settings can be Changed and at once and then told to rebuild all at once so that only one rebuild is occurring The variant record only changes once as opposed to numerous times Some of the more Familiar with some advanced concepts might be wondering why I didn't put these conditions within the menu item itself Because that would also be another way of doing things and it had to do with an op Essentially what I'm talking about is where each menu item Holds the condition on whether it's publicly visible or not The reason why I didn't go with that approach was essentially another optimization that when you have to look at your use case and in this type of situation and see whether or not your Changing it a lot or reading from it a lot and in my case I was reading from it a lot so not having to call One of those checks every single time you read something just to see if it's visible or not Cuts back on the amount of work extensively Because if we read through the resulting menu after it the builds has been called there are no conditions at all It's just read this thing doesn't match read this thing doesn't match if the conditions exist within the menu item then what we have to do is Read this thing is it publicly visible doesn't match go to the next thing Is it publicly visible doesn't match so because it wasn't being rebuilt a huge number of times But it was being read from matched against over and over and over again several times a minute was far more important to optimize for that Now show this off a little bit just to show how this basic absolute basic example works This you see no condition in so this will always be in what is essentially the the variant record output of the machine This will always show up, but will show up in a different form based on various settings Essentially, we have the full-blown item to item to with limitations essentially saying that option one is somehow a more limited form of option two and Just say setting 10 is the addition of something else to certain items Because that's off in this last case Then it would be all have this claimer Without something entirely instead of just with the limitation Now if we build this and run it Immediately because none of these have ever been set the only thing that should show up is this item item one and it does So now if we set what was that setting? Six if we set setting six to option one and this would normally be done by like a launch page and Some commands that can be written run all the things operating, but This is doing this for now because I don't need to write a whole other command parser Just to show this off and you can see there's the second item and It's correctly without something because option 10 Was off essentially it wasn't set, but I Just still tends to pick sane defaults and in the case of an enumeration It's gonna be the first one which of course is off We change this to on you can see now says with the limitation, which is correct because This was only option one We set this to option three which was above the option two that we had set It should still be there, but now without the limitation at all And it is Yes, one thing left to do is If we set this to off because at least in the builder that we had set option Option setting 10 had nothing to do with An actual value in and of itself it was just modifying these So now we should see only the first item so to reiterate I had a bunch of settings that interacted I could not implement a one-to-one mapping between any specific setting or any specific input and The resultant state there was a group of settings that Defined the state because of this The state machine could not be implemented using a Using a dictionary list an associate of array a map whatever they're called in the language you work with in my case The state machine has a slight optimization by which it accepts a list of tokens that needs to be changed And then a build event This allows changing multiple states at that are changing multiple settings at the same time Then telling the machine to change state based on the setting changes as opposed to changing every single time That the token is sent off This is because the individual changes don't matter Sort of like a cue for a ride You're not sending one person off sending the ride off one person on the ride sending the ride off you Take a whole group as much as you can and then send it off Just a slight efficiency thing. It doesn't really change how it works in any Serious way just just a slight efficiency thing But then the result of this state machine is a sort of variant record sort of as I was able to roughly implement it in In JavaScript because this was in JavaScript As far as I know JavaScript doesn't have any concept of discriminants. So the state machine was acting as the discriminant maybe some of the more advanced JavaScript programmers out there could point out a I'm sure I'll get plenty of more JavaScript ways to implement this that I See how those work out But there may be a better way to do this in JavaScript. This is just where I was coming from This did work phenomenally well other than a few typos You know using the wrong sign somewhere or using the wrong actual value somewhere or forgetting An additional setting that should have been part of the condition That was The extent of the bugs in this now you have an insane amount of different things that would need to be unit tested and This thing has been used several times a week by this individual Without any bugs now for like six months Without any bugs within this there's other There's other parts of what I've written for that individual, but No bugs within This for that individual which is quite impressive given the massive amount of complexity involved But you can see the approach to dealing with this broke it down into very very simple terms I'm not sure how much this specific example will help you point out when you'd want to use a statement Versus when not It's sort of a hard thing I Find it best when you just kind of understand the tool and then you can kind of Think to yourself. Hey, this might be a good place to do that and then you can learn from whether or not that worked out or not I don't really have any good guideline for that. There are definitely situations in which state machines add too much complexity, but they're Definitely situations where it saves your ass is it certainly did here Oh Like I mentioned when I first did this there was roughly 16 settings and we added three more later We've added numerous menu items. I don't remember how much were there when I started but adding any of these was literally something that would take about two to five minutes and Wouldn't even need to be tested would just send off and would work Again, no no bugs within this for like six months Anything that was a problem with it was literally just a typo that like oh I hit the wrong key That was it. So hopefully found this video helpful if you have Consider giving a thumbs up and if you like what I do in general Please consider subscribing maybe hit that little notification bell Subscribing helps me out quite a bit and it's not super obvious because YouTube doesn't really explain anything to people Have a good one