Elm Europe 2017 - Evan Czaplicki - The life of a file

well welcome everyone I want to start just saying thanks to everyone for coming this is it's kind of crazy I'm Evan I made Elm and it's very exciting to be here so I want to say thanks thanks one things for folks thanks folks for coming thanks to Tebow and Guillaume for setting things up and then like thanks to everyone who is helping get the technology set up and then like this thank you is like out of proportion right so like thank you to who who had the L have this tale I I really appreciate that yeah so thanks everyone for coming and I want to emphasize sort of a question that that I the has sort of guided Elm for the last couple years which is how do I grow elm code and so this is a question that somehow always sounds topical so who remembers Elm before the Elm architecture before that market okay there are people there are people out there okay so there was a time when that didn't exist in people would say how do I write a program and so we sort of observed okay maybe we can call this thing there's a model there's update of you we saw that pattern and they're like okay that's cool how do I grow an own program okay so we had some more examples and showed okay you can reuse functions in this kind of way to help make a view and people are like okay cool but how do you grow an elm program so I want to take the next step in perhaps a never ending journey and we're gonna do that by tracing the life of a file so we'll see it start small and gradually grow and then grow a bit more and eventually break off into two and I think as we go through this path it will necessarily be surprising or difficult but I think it's hard to see if you're coming from JavaScript so before we get started with the life of a file I want to start with some JavaScript folk knowledge than maybe leading people astray so one thing that I see a lot is this idea that like shorter are better so an extreme example of this is when I was doing the the benchmark comparison between react and a bunch of other frameworks in Elm the ember one just had so many files I just didn't get it right like this is a greater than file and it just felt like this surely isn't the the easiest way so when I see this this like thought process it sort of feels bizarre to me and so the way I can understand it is the contact is as then as the lines of code increases the probability of sneaky mutation approaches one like it's going to happen if you're writing JavaScript code so if you have a thousand lines of code there's going to be some object that accidentally gets shared and two people are going to be mutating it it's just going to happen so therefore for shorter files it fills this very useful function another thing that people just know in JavaScript is you have to get the architecture right from the beginning or you're doomed it's just like not going to work out for your project this you like barely need a justification because it's like obviously I'm sure many of us have seen this hat play out in companies we either work for or people we know and the justification behind is like refactoring is very risky sometimes it's cheaper to just rewrite the code and I think that accounts for some of the churn in JavaScript frameworks people like the list didn't work I could try to fix it but it'd be just as easy to try a different thing that maybe doesn't suck so we have these sort of intuitions and habits that are grown out of actual constraints of JavaScript in and of the languages we use but in Elm the probability of sneaking mutation is zero if you have a thousand lines or ten thousand lines it was like not possible that a value gets shared and suddenly there's spooky action at a distance between these two chunks of code so this whole premise is gone and so I don't see how we can draw the same conclusion anymore similarly refactoring is cheap and reliable like you have types to help you out the compiler is going to guide you through the process so you can end up changing 10 or 20 files and be pretty confident the end that things are fine so again this premise is gone and so this idea that the architecture has to be right from the start doesn't really play out in practice so the big thing to note here is that the way Elmas design changes how you should grow codebase and we have a lot of habits that come from like we don't even necessarily all know the justification of these things but we know like oh that file seems too long that's probably that like we have these senses that guide how we write code so the rest of this talk is sort of challenging these and providing a new way of seeing code that can help grow a program okay so the life of a file we might start out with a nice little file let's say I and the blue is a like the model let's say the data structure and then there's some logic and maybe this is I have a personal like reading list and I want to just keep track of the books that I'm interested in and maybe I have two 200 lines of code I'm not crazy and so I add some features I want to be able to mark the books is read or not and maybe I want to reorder them depending on if one starts to see more exciting and so now I have about 400 lines and I think a lot of folks at this point would be like like something's wrong there's a problem that's generally not that's not how I would approach programming in Elm it's not how things work in standard ml or a camel or Haskell is just like having a file this long is pretty standard so if I go through the compiler like that's I take the average and so maybe I had some more features I can add annotations to each book of quotes that I really like things I want to remember so now I have like 600 lines of code and it's like okay now it's truly it's a problem and not really I don't know I think you shouldn't like be too scared of a file growing long so this is something that will typically happen now at this point it's likely that I'll say you know what I think it'd be good to have the data structure for like my library where I can reorder books and a data structure for books where is it read or not what are my notes and then I can start to organize my code around those two data structures so I can say okay mark this book is read add this note and so the functions in my code start to organize around those data structures so anyway you discover this better data structure so the next step that may happen is we split around the data structure right so once we discover that there's this other way like chunk that we can grab on to that can become the heart of a nice module and so this is the typical process that I always followed it's just basically grow until I find a data structure that I can split on and if I don't find it that's fine so I'd encourage folks to sort of play with this in your own code and sort of if you're feeling uncomfortable like oh this seems like I have too much code here just like push into that feeling and like see if it actually is warranted like is there actually a problem or is it just like a feeling that you have based on experiences in other languages so okay so at this point this is basically just like a unsubstantiated claim let's see some more concrete examples right ones where the code is more elaborate than lines so okay so I want to look at two examples one is the sort of settings so you can imagine this is like the settings you'd have in a Facebook or Twitter or Pinterest or whatever like do you get email notifications do you want video audio play do you want to use location these kinds of things and that you could just say no but they want to give you the option to say no the other situation is checkbox is a bunch of fruits maybe you're going to get lunch and you are able to pick out which fruits you want then you can have that one so before we dig into this I want to sort of take a second to and ask people like what are the questions and concerns when you see these two they that pop into your mind like when you think about how the code is probably going to look what pops into your mind okay yeah someone said oh okay okay okay we're good we're good someone said generic checkbox list so yeah this idea of like how do we share like clearly we have checkboxes here like sharing needs to happen okay this I'm gonna I'm gonna proceed by showing how I would address these and then we'll see if that intuition plays out so when I look at the settings the first question I ask is how do i model this information right so do I use a record where I say if there's email there's video there's location do I use a list of pairs where the string would be email notifications true autoplay false location false do I choose a dictionary which would work similarly but now it's unique on these things or do I do this other one that's I have a list of strings these are all the options so email autoplay location and then a set of which ones are selected so this would just be email and we can think of more it's a good idea to get in the habit of just thinking what are all the possible ways I can represent this so at this point you want to say okay well which one should I do so one trade-off here is this one gives us the benefit of types right so if we're messing around in our code and someone misspells email or misspells one of the things the compilers going to give us some help so that's nice and these other ones are string we typed so if there's some misspelling it's sorry like things are going to go weird another thing to think about is the order in this one is just determined by the view so in my model in my record I can update however I want it can appear however I want it to appear in my code but ultimately in the view I'm gonna say show the email show the notification show this and if our designer says ok we actually want to move use location above because everyone wants to turn that off and no one can find it we get a lot of support tickets and like they're really mad at us so like like I get that just change it ok and then it becomes very easy in this world with this one the order is stable but you can actually change it in the update right so we could in the same time we're up ting a bool from true to false we could just swap reverse the list and so suddenly the UI is totally different based on stuff that's happening in the update code so someone writing update could have to think about what was it that that designer said a while ago about support tickets this one orders depending on the keys it's just like not a good idea and this one the order is stable again so it seems like we've got a pretty clear winner in this case so let's just run let's run with this so done ok so here's the initial version of it we can check stuff and we can this is kind of small but we can see people messing with the record oops ok so when we look at the code can people see this ok ok the model is what we talked about we have the record with our boolean fields and the defaults you know everything needs to be true right we need autoplay to get that add money we we need location on so that it can be location specific advertising ok I notice you're in the neighborhood of and we need the email so that they can notify you to log in and see the autoplay heads and then in our update things are relatively straightforward we have a way to toggle each of these things and if I mess up and say I want the models email it's like hey I think you have a typo so we're getting that benefit that we wanted and finally we have view so we have a field set there's labels and each one contains a checkbox bits we say okay here's the email notifications one is it checked here's the autoplay is it checked etc now one of the things that you can do is they okay these actually are pretty much exactly the same so we can factor out some of this code so I can save you check box I don't know if it makes sense to start with the type but if--like practice this so I know what it is but we can essentially chop out this code which appears a bunch of times and [Music] fill in the blanks so checked is checked message description and then where's - where'd my mouse go okay there it is and then we can say let's just replace all of these with you check box okay so is a coach shorter not really but if we are applying styles to all of these in the same way now it's a lot easier we can do it in one place and be sure that it happens everywhere so this is a nice refactor given the current state of affairs so let's see if I did it right yeah okay cool so we come back we have this going it's nice and so we get a new feature which is autoplay customizations right so instead of just autoplay we want people to be able to choose should it play audio by default and should it play on Wi-Fi only or will people allow it on on cellular data as well so when we go back the thing to look at is our model again so one way to deal with this is well okay we have two new things so we have autoplay audio and autoplay Wi-Fi it's I'm gonna call it without Wi-Fi I don't know because it helps me understand what the bull would be and then we can go mess with our view but this is kind of lame because we we we can do it that way and the designer will say well I want it to be aware if there's no video autoplay then you can't mess with the autoplay settings right like you're not doing that so there should be disabled so suddenly we have this interaction between these three fields where we always have to check autoplay before we show this and that determines whether it's disabled so we're starting to get these dependencies so a better way to represent this would be to just actually model it directly so autoplay is offer on and if it's on there's audio or without Wi-Fi so in this version of reality you can't mess with any of these options without pattern matching on on or off so if you want to change them you have to say okay let me expand the autoplay if it's off well I don't need to deal with it and that also means in your view you handle these two scenarios and you say okay is autoplay on in which case I can show these things if it's off then I don't so it's sort of forcing any future user of this codebase to understand that there's a dependency between these fields now we say okay we'll show this to the designer again but the thing is if we turn things off we lose all of our options so like we want those to be preserved some users will toggle this a lot and it's annoying so what we can do is say okay type alias autoplay settings and then we can actually just have it on both but still force people to go through the on/off check before you're doing any logic so and then this will play out throughout the course of the code we can we can a way to approach this was well now we have this autoplay idea maybe we can start to write some helper functions to make it nice to work with so maybe we can say toggle autoplay and it switches between on and off in a nice way and so as we create these helper functions we start to have functions that are all built around the data structure which is that pattern I was talking about so once you start to see these kinds of chunks of code you get these units that can break out and make your code nicer okay so we have that going so now we come to fruits and at this point the question ask yourself is like do you think it's going to work out the same way so yeah so let's take a let's take a look so again we can choose between different data structures and I picked the same ones so record list of things dictionary the list of options and which ones are selected so in this case our constraints are very different so we work in like fruit fruits comm I don't know and the fruit availability it's seasonal we want to bring you the freshest seasonal fruits for your region and like maybe we're out of bananas today so we don't want to just let people say I definitely only want bananas oh sorry you need here's a mango so if we use a record does that mean we would have to ship code every time availability changed in a particular region or so that doesn't seem great but in all these others we can just load the options from the server that seems like a benefit from there one thing we might consider is well which of these will be easier to just to use which were and what will the code come out nicer so in this case we'll probably use lists that map to do an update we can scan through and say if it's this fruit then I'll toggle it or not with dictionary you can use update and say ok I want to change this particular fruit and with this one we can use set insert and remove so we don't have to ever mess with this and we can just say ok they want to add this to their set of their selected set and they want to remove that one and again we have the ordering problems from before we're like maybe our head of fruit marketing is like we need to put bananas up at the top because that's like higher margin and that's what we're all about here at fruits calm or maybe someone else is like well we really should put mingoes over the top think about the nutritional content think about the bottom line so there might be some need to change this around perhaps dynamically so again dictionary isn't ideal for that kind of scenario so let's let's go with this one where it'll be kind of nice to add and remove things to the selection and we can mess with the order quite easily okay so now we can go look at our fruit situation which and then we can just select it's it's great and if we look at how this goes we have our fruit list which is very stable and then selected which is changing as we mess with stuff okay so let's check out how this code works fruits okay so in our model we say we have two things the fruits that are available and the ones that are selected and for our initial model we're just pre-populating with some fruits but you could load this from the server and our selected set is none are selected and then update logic pretty straightforward if a fruit is selected added to the selected set if it's deselected remove it from the selected set and then it's going to fit yeah okay cool so in our view code we again have a field set I don't okay you can see the mouse here we have our field set and then we're mapping over all the fruits and so when we do that we say okay I have a fruit is it in the selected fruit set if so it's checked and then we draw things in a in a way that looks quite similar to what we saw in the previous example so it's a check box whether it's checked or not what the title is but the thing that's actually interesting about this code isn't the part like the part that they have in common is like whatever seven lines it's like not very crazy and the chances that they're gonna stay exactly the same between these two different chunks of code is like very low so thinking like focusing on just this like oh I've seen a checkbox before somewhere like doesn't really give you a lot in terms of the structure of your program so at this point we have a pretty good pretty good fruits app going on fruits comm business is booming margins are good okay but a new feature comes along which is only two fruits can be selected we have all these folks out there who want like three fruits six fruits even we don't have we don't have the distribution channels for that so we want to cap out at two fruits per person you know pick a favor like pick a side so this is kind of a tricky situation we we have found ourselves in so we have this set and we can they need to limit the size somehow oh there's one other constraint which is we need to check out a different fruits no fruits one maybe no okay I do eat it a file that I should not have deleted but the thing that I wanted to show was we want to maintain the order that they were selected so if I select Apple then apricot then banana I want the oldest thing to be the one that's forgotten so I want to keep the most recently selected as I go through things so with a set it's really hard to keep track of what was the order that things were added we can remove one of the things but we don't know which of the two it was so you'll get this very wonky behavior so at this point we can ask well maybe it'd be good to think about the data structure we're using so we want to choose two fruits in particular so maybe we say okay so I'm going to choose a string and a string but what happens when nothing selected all right we need to account for zero selections one selection two selections so that's no good maybe we can say maybe string so all of these can be optionally selected but there's this weird case where if one thing is selected we don't know if it's going to be the left or the right thing so this doesn't seem great either so maybe we can say okay there should be this type too and it's either 0 or 1 or 2 ok that's pretty nice you can imagine inserting into 0 you go to 1 inserting into 2 and then into you maintain some order moving things along and that design seems ok but we know we know ahead of fruits marketing he's going to say ok well in tropical areas we can actually give them more fruits so they're gonna want a limit of 3 but in Iceland they only get half cucumbers there that's just the rule I don't know that that is actually how it works so we're probably not going to be able to just stick with 2 there may be some place where we need 3 or 4 different limits so another way we could do this is just a list of string and then limit the size so essentially add to the front and take things drop things off the back so I don't know it doesn't seem perfect like clearly you can just add 20 things to it but it sort of has potential so let's let's explore that route so instead of this being empty this is empty list oops the cursor just like disappears anyway so when we select something we want to say list take 2 fruit on the front of our selected list so this is saying put the fruit on the front and then just take the front too so whatever else is there we'll drop it and then when we deselect we can say list dot filter the fruit should not any fruit that's not the one weed that's a lot of knots in one sentence we want to only keep fruits you get it what's that for it to be deselected and then in our check box code we want to say and said list that member and I think that's everything except we don't eat that anymore okay so let's see if I did this right hey and so you can see it's maintaining the order that I click things so if I I don't know it's kind of hard to remember it's easy if you go and order and you can see it's it's working nicely okay so we're maintaining our two fruits per person situation but when we come look back at our update code it's getting it feels like trickier right and as we grow fruits calm like maybe someone won't realize that take two is not just to some find choice it's like head of fruits marketing decided that was too and you can't change that stuff so we want to have some more security around this code so one way we can do that is to start to break out the particular stuff around that data structure so we we know there's the selection list we can make a function that is along these lines so let's do it in the update part insert oops insert fruit list I'm gonna leave off types for now just the speed and then I can say here insert fruit and then I can also say remove fruit from the list and we'll do it the same way so this code gets a bunch simpler as well remove fruit and we can do the same thing with the checking for membership below now at this point it's sort of coalescing into there's this kind of data structure that's specifically about maintaining just two things in in the list so I'm gonna check for time to see how much live coding I should do okay well let's let's start to follow this idea of like well we're starting to recognize a data structure so let's try to break that out so I can say fruit list and I have this type alias fruit selected fruit so we're starting to see the the beginnings of a of a module like things that we can box off and put in their own place so I'm going to just skip ahead to a version of this in a different module so the idea is we have this thing called the bounded set and ya know that shouldn't skip ahead to this that was a bad idea so let's say okay we have this and we were going to put it in a new module the selected fruit module exposing selected fruit and then in our fruits module we can get rid of that and we can import as selected fruits and then we just have to go through and make a couple changes here Oh we'll come back to that selected fruit that insert/remove etc so this is also selected fruit we're kind of leaking details here okay let's see it okay check does this work no selected fruits it's singular there's also a stray friend spelling it's it's nice that yeah oh geez what the heck okay [Applause] just imagine there wasn't a compiler there we're just like maybe that's wrong I don't know okay so this is still working but we can kind of improve things by sort of closing down this module right now we're exposing everything but we could do better by saying okay from the outside no one knows how selected fruit is implemented it happens to be a list of string but no one needs to know so we have to do a little bit of selective hey I have I'm disenchanted with this naming choice okay so now from the outside no one knows how the particulars of this are implemented so let's just run it this is supposed to not work so we're using this dot member on a selected fruit but we don't actually know the implementation deals of that anymore and are selected we're saying it's a list but we don't have access to that information anymore so we need to add how do I make a empty selected fruit and that would be selected fruit is empty and then we need to test for membership and then we can just say list member fruit list oh it's still broken because I didn't actually change the broken code so here we say selected fruit is empty and then member we say selected fruit I'm member cool so now now we have sort of hidden all these implementation details but we can do slightly better right so maybe we want to make a guarantee about the size in this data structure so we can say will actually give the maximum size when we say it's empty or not and then in all these cases max size so instead of taking two we take the max size and instead of removing you know we'd to keep this the same but we just have to keep the max size around and then here we don't care about the back size we just want to check so we should have an error because we're just calling empty without saying how big it should be to all right and then things should work again cool so at this point we sort of taken all this complexity around maintaining the only two things are selected and put it in its own module so the benefits of this is that when I'm reading through my normal code all I know is there's some way to select fruits I can say how many and then I can insert and remove and these things will just work out nicely and I can check if something as a member of that so you can go like one level crazier with this which like we shouldn't get into but you can so the idea was you could generalize it so that it's a list of anything not of strings or particular fruits and then everything works the same right you choose the size you can insert things into it you can remove things from there you can check membership so all of these designs are possible and the question is which one is right for your situation right should you go like all right I'm writing my own data structure that's generic and all sorts of things and I'm gonna optimize it or is it like look it's just a list it's not a big deal like we're probably not gonna get it wrong and so that depends on what's likely to happen maybe at fruits calm you can make one choice but if the new fruit stand startup oops I don't know they they want to make different choices okay so the big lesson here is that we started with two things that look basically the same and ended up with entirely different ways of approaching them that was all about the data structure right and it is true that they share check boxes but that's such a small fraction of the actual difficult things that are going to happen in your code that it makes sense to emphasize the data structure instead so I want to put a little extra emphasis on the module right so I showed this bounded set idea and ahead there's a bounded set if it's empty you you can insert things into it you can remove things from it you can check membership now the most important part of this module is the exposing line okay so I'm not exposing everything in this module and specifically I'm not exposing the implementation of bounded set so no one from outside can mess with the maximum size and as long as these functions work things are going to work so I want to point out two little benefits that come from this so if you reduce the public API to your module if implementation is hidden and if the public API works the code works everywhere right so like if I try to break the break this code by messing with these functions and I can't do it anyone else who uses this code won't be able to do it either so this is actually really nice for testing because it means you can test the public API very extensively and that doesn't mean you have to test every particular usage right using this data structure somewhere it doesn't mean I can introduce bugs into that data structure retroactively Lee if it works it's going to work well the other thing that's nice is you get easier refactoring so I can change how things are implemented without worrying what's going to happen outside so and this happens in a couple ways one is say there's an insert help function that's doing some extra-special stuff I know that it's not exposed outside so I can mess with that the arguments add arguments change shuffle things around and be sure that this is not going to have any effect in any other modules I'm not going to have to go hunt stuff down that's also nice because it means I don't have to worry about if it's used in ten different places across the code did they need it to work in a very particular way in each of those cases and I'm an eye covering all those cases I can just say oh it's not publicly exposed if it works in this file it works so the other thing that you can do by creating modules in this way is maintain invariants so in our case that's only two fruits but generally speaking this means there are rules that cannot be enforced entirely through data structure design so we had our two which is zero one or two but that wouldn't let us decide how many we want so we now have a data structure that can let us decide and by hiding all the details we can still maintain that rule in a safe way even though we can't do it purely through data and one cool thing about finding invariants like this is that they're excellent for fuzz tests right so I know that whatever I do with this if I say my bounded set has two things no matter how many times I call insert it should just have two things so it's a by thinking in this way you also set yourself up to write tests that are nice and are checking the kinds of things you're worried about so I want to add some warnings to this advice so first if you find yourself writing get and set right so we hid the max size but maybe someone's like well I want the max size I won't do a bad thing with it okay this is a bad sign this is a bad sign when you have getting set so the whole point of having a module was that we were able to hide implementation details and say if you use this public API it will work and inside you don't have to worry about that we tested it we know it's good setters their whole point is to expose those details right so like you've done all this work to put it in a module and we we went through that together it was like it took too long and now you're gonna give setters that just totally defeat that entire exercise so just use a record if you have data where you want people to have access rather than hiding the details then exposing getters and setters is like these details aren't hidden so don't do the work to to hide them so another way to say this is expose as little as possible but no less right some things do need to be publicly available so this isn't this shouldn't just be like hide everything that's better the other thing is don't don't overdo it so I'd wait until I have a problem in practice and then solve that problem so the goal shouldn't be let's just write modules because modules help with this kind of stuff it should be hey I'm having trouble understanding this code I came back to it after a month and it seemed kind of confusing maybe I can find parts that I can make things nicer so if you find yourself asked how do I make the sidebar reusable okay try to remember to ask yourself why right like are you gonna have multiple sidebars maybe not in which case like why would you do the work to do that if you are going to have multiple ones a thing to think is are these cases the same or are they similar right if we're just talking about the HTML is going to look similar but how it works behind the scenes is fundamentally different in both cases I think it's probably not a good idea to like try to get all into how do we share code between these two focus on the data structure instead another thing that might happen is eyes are growing your record you don't have any interesting types like you don't have that autoplay thing where these fields are depend on that field and it's just a bunch of independent stuff if they're all independent there's no problem if I just have fields that have no relationship to each other and I change one there's not a chance that there's some bug elsewhere but if I do have that relationship that's a potential to start finding a data structure and do better modeling so I'd say like don't be afraid to just grow your record and try to find these connections and how things fit together as opposed to preemptively like ah like I'm worried about the this code so I'm just going to change it so yeah just as there's premature optimization there's premature refactoring like you should it's a thing it's fun right like it's like you get to play code golf at work I don't I I don't think encouraged employers should encourage that but people like to do it okay so to take a step back we we saw how to sort of how a file tends to grow right and if we focus on the data structures we end up with these nice categorizations where like when I'm searching through a codebase even I say hey where's that stuff that's related to books it's probably in the module about books right as opposed to well there's this update subdirectory and all the update code is there and the book stuff is in it's just like it's relate to books so yeah so big lessons are focused on data structures and choose the best representation available so I actually think through as many cases you can and the others build modules around types and try to expose as little as possible but no less so yeah so I hope this will be a nice next advice in the how do I grow my elm code and one of my goals was to to write this up so I actually started a book that is about functional programming in elm and the goal of this book was essentially to write this talk so that people could read it online and it would work out it turns out is very hard to write that whole live coding section so instead what I ended up with is some nice stuff about recursion and graphs it's fun hopefully I'll be able to distill this down into another chapter that actually emphasizes these things in a way where you don't have to see the live talk but yeah so that's the life of a file thank you [Applause] you you

Channel: Elm Europe

Views: 51,914

Rating: 4.956718 out of 5

Keywords: elm, elm Europe, 2017, conference, talk, keynote, Evan Czaplicki

Id: XpDsk374LDE

Length: 47min 1sec (2821 seconds)

Published: Thu Aug 24 2017

Reddit Comments

[u/Brasilikum]

The moment you realize that the only thing more friendly than elms compiler messages is it’s creator

[u/[deleted]]

Really great talk. Definitely bookmark-worthy to go back and watch again.

This part is certainly interesting and IMO is the start of a conversation with the UX/Design team.

If the user experience of these two checkbox list views should truly be the same and consistent (they have the same invariants) then that is an opportunity for reuse. Implement both features and reuse the same view functions if they have the same invariants.

Now let's say requirements change. In one view there is a behavioral change. We need nested checkboxes. The invariants for that module changed. That's fine. This is the start of a conversation. Should the fruits checkboxes exhibit the same behavior? The fruits list still need the original behavior? Ok, let's create a new module that allows for nested checkboxes and guarantee the invariants we want for the nested checkbox module. We are no longer reusing the same code because there is a significant difference of invariants.

Requirements change again. The "fruits chooser" needs to allow a maximum of two fruits. Ok, no big deal. That's another convo with the UX design team because the invariants changed again. Does the original checkbox list need to exhibit bounded behavior? No? Ok let's make a module for a bounded checkbox list and discard the original checkbox list module.

I don't think the fact that we're talking about reusable views makes it different than any other Elm code. We're still talking about reusable functions and creating modules that maintain invariance.

[u/ShadowLinkX9]

Haha I was wondering when this was going to be uploaded. This is a great sequel to impossible states