Check out a free preview of the full Hardcore Functional Architecture Patterns in JavaScript course

The "Composition Architecture" Lesson is part of the full, Hardcore Functional Architecture Patterns in JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Brian compares working with one big function that does all the work with little functions that represent small functionalities from a given application, and says that this course will focus on composition involving multiple small functions.


Transcript from the "Composition Architecture" Lesson

>> Over here on the left, we have a bunch of pieces that we're going to assemble, little Legos that we're exposing to the user. On the right, we have a purple box. And so this is kind of trying to capture the idea of a little, bunch of little functions that you compose versus one big function that does all the work.

And one of the benefits here of the little functions that we're composing is we get infinite use cases like the combinatorics of all the ways you can compose the functions to create new functionality. We're just giving those to the user and say, you know, saying go, go nuts.

Have fun with these these functions and make your own apps. We end up with little simple, understandable pieces, often highly reusable, lots of, lots of goodness here. But it's also hard to change the implementation. It's harder. And if we're gonna try this, the way we get flexibility when we give all the pieces to our users to compose is by enforcing that each of these pieces compose in a principled way.

And we can change the implementation all we want as long as they still hold the contracts that we're defining. So this is largely how algebra, abstract algebra works is you have these pieces that you can pose in many different ways, but those pieces have laws of composition, and you can implement them in many different ways.

So that gives you a lot of flexibility but you have to really work at that. And it's also harder for the user to compose, right? They have to go like, put all these pieces together all the time. Getting into the other side of things, the extreme other side where we have a box, you give me input, I'll give you output, and it does everything for you.

While we have a lot of flexibility and implementation changes we can take a value and do whatever we want as long as it returns the same output. We can we can change this all day long. But there's less use cases out there to support and they only can kind of do one thing with this function.

But if we're capturing this procedure with a name and contract, and we're representing out in the world to be composed with other parts of every other program. Essentially, you're gonna inevitably run into a case where you pass in an if else or some kind of flag, or something if you wanna reuse this unit in different ways, so those conditionals get pushed into the box rather than being out when we compose in different ways.

Does that make sense? I'm talking pretty abstract right now. [LAUGH] But the idea is that if we write one giant function, and we need to use it in different places, inevitably if else is within the function. We can't satisfy all the cases with few if else's, right? The is minimal compared to providing a bunch of functions for composing.

You get way less so sometimes this is the right decision. And sometimes this is the right decision. But we're going to focus on this decision today. And that's because, most of the time this will pay off in your application development. This one over here will pay off much more when you're developing a library that does one thing.

So just as a quick example of the abstract algebra stuff, this is the definition of group from Wikipedia, and we can define so many groups. If you look at like instances of groups, they're just like everywhere and they're free to implement in different ways, as long as they satisfy these properties.

This is what your documentation can look like. Versus, you know, it's called this and take this and put to that output and you don't know anything else about how you can compose it. So one last note on that is sometimes you build an app and its like this and its wonderful.

Like, this is, you know, my library, this is my application. We have all these little functions and you compose them, it's great. And sometimes it's like this. And composition doesn't really buy much. You really gonna have an awesome like one of those, called car cruiser fighters? No, I'm going to be in so much trouble with the internet.

>> X wing
>> X wing. I guess it makes an X. Yeah, well, anyway Star Wars battle flyer thing, you're gonna have one or you're not gonna have it, right? It's not going to be very useful for the user to have to recompose this thing every time unless it's a fun game for the children.

So we're gonna favor composable functions, mostly. I just wanted to call out that caveat like if you're if you're always you know, abiding by these these principles, you might make the wrong decision. Sometimes it's just a good guiding light into the right solution most of the time.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now