By far, one of the most important factors of this whole pattern is that of readability and maintainability. We all cobble together code while we are solving the problem. The thing that never happens is the most important step: clean-up. We need to always consider the one who is coming behind us to change, fix, update, or test our code. They weren’t there when you decided to put in a reverse sort before a decrement loop that includes some array splicing. Not only do they not understand the nuances of what you’ve done, the likely don’t have a clue why you’re even doing the loop in the first place. Be nice to them. Far too often I find myself as that them and I have a suspicion that those moments take days off my life.

We want to write clear code and put in reasonable “why” comments along the way. I like to start even partially complicated blocks with an outline of comments. Maybe something like this:

I know that looks trite. But that is often where I start. It helps me nail my logic first, then I drop code in between the comments. No, this isn’t part of SOOJS, but if you understand that one of the major things the pattern will do for you is to create much cleaner code, then why not assist a little.

The second part here is to clearly separate our logic. I know, this is like 101, but it’s so very simple in JavaScript to not do this. I’ve come across far too many misplaced inline functions that were obviously just easier. It’s not helpful to the next guy who is hunting down the 4 places someone can log out of the application to make sure each inline function call is updated properly.

These are so quick and easy to drop around in an application, but there is something nefarious about this. We are encapsulating business logic and view logic in the same place. In this scenario that may not seem so bad, but when we realize we also need to remove a cookie before logging out we have to add:

But we have to add that everywhere. And the guy adding it is not likely versed on the entire application. He’s unaware of the links that have the “logoutLink” class. And he doesn’t know to look through the source code for that class to add his cookie remove logic. And that may even make it past the testing team for the same reasons.

So, inline functions are awesome and, in fact, many times required to unlock the full power of JavaScript. The issue isn’t with them it’s with the duplication of code and logic. What we should see is:

That has solved our problem. The developer tasked with deleting the cookie on logout knows what his part of the system is: Log Out. He doesn’t need to know the UI at all, nor who calls the logout() function. He can rest assured that anyone that wants to log the user out will use this function.

But that’s not quite good enough. This is where many projects get stuck. JavaScript doesn’t give you a lot of signposts indicating where certain code should go. Should we create an application library for this logout function? Should we just attach these (as seen above) to the global scope? How can we find it later, or at least know there is such a function already? Should they all be in one file somewhere?

SOOJS helps here by defining objects in the application that control the different parts of the system. In this example we would create a StateController to deal with application state changes like this.

It’s important to understand that there is no magic in SOOJS. No words are reserved or special in any way. Creating a controller is the same as creating a connector. In fact they follow the exact same pattern. The words “controller” and “connector” are there to define the type of object — and thus have some expectation of it’s responsibilities.

So, we create a SOOJS Class called StateController and put it in a new file called StateController.js. There is no ambiguity here. If you need to know what this controller does it has it’s own file for you to look through. And if the developer needs to change the functionality of logging out then they can feel confident that changing the “logout()” function in this class will cover all scenarios. They have no need at all for a deep understanding of the entire product. And unit testing is as simple as finding one place to log out to see if their new changes work.

This is the very beginning of the SOOJS pattern. The above is NOT formatted properly for SOOJS and only there as pseudo-code. But now we are getting closer and closer to the real pattern. Hang in there.

Series Navigation<< SOOJS has classCore Concepts: File Separation >>