Macrodopache Flex. That's what I'll call it - because during it's different incarnations it was managed by Macromedia, then Adobe, and now Apache. This brief intro is for all the Flash haters out there.

Flex is a "Rich Internet Application" framework built on top of Flash. That's fancy talk saying it was Flash for banks and enterprises and big intranets. I got into Flex at version 3 - at the point where it was reasonably priced and not server side.

I didn't work for a bank, I got into it because, as a Flash developer, I was sick and tired of creating buttons and dropdowns and other common UI components from scratch. Flex had a way for me to sweep the boring repetitive bits under the rug and work on my unique snowflake of an application/game/interactive.

What was frustrating about Flex 3.0 was it's ability to be skinned at any sort of deep level using any asset you wanted. I went deep down the rabbit hole in making Flex compiled libraries out of Flash to import them and use the assets. Overall, it wasn't pleasant.

Then came Flex 4.0. Lots of folks complained how different it was, but for me it was awesome. Most of the awesomeness was the ability to use "states" and design add any custom elements - vector shapes, bitmap graphics, or whatever to your states.

The simplest example of this was the button. A button has an "up", "over", and "down" state. "Up" being the normal look of the button, "over" is what it looks like when the mouse is hovering over it, and "down" is the state when the user is in the process of clicking it. You can add more states of course - like selected for a toggle style button. The main point of this is to say that there are visual states.

In reality - what is happening here is that all of these states exist, and a "state" variable dictates which of the 3 visual layouts/designs to show. It didn't really care what the contents of your visual state was - you simply defined the look of each state and what kind of component it was, and Flex would handle the rest.

Sometimes your component might have some bound piece of information inside. Like a labeled button: you might create a button labeled "click me".  This label needed to be identified in a common way and bound to the component available in all states you wanted the text to show.

Bigger than that even - was the concept of "Application state". Really - take the concept of a button, and scale it up, defining whatever states you want.

Say I have an application that allows a user to log in, list people, select a person to edit, and then log out. My states might be  "login", "list", "edit", and "logout". In HTML/JS/CSS world, we might have those on separate pages? How about a single page app?

Yes, there are numerous ways to do it - but how about states? Take this concept in Flex (and yes it's common to any number of platforms - I believe I've seen it in MS Silverlight and Android) and adapt to Angular.

First - how to mange if one visual state is shown or hidden? Well - how about creating

<div> class="state login_container">....
<div> class="state list_container">....
<div> class="state edit_container">....
<div> class="state logout_container">....

div.State {
  display:none;
}

function AppController($scope) {
    $scope.state = "login";
....

<div> class="state login_container ">....
<div> class="state list_container ">....
<div> class="state edit_container ">....
<div> class="state logout_container ">....

div.State {
  display:none;
}

div.state.login_container.login,
div.state.list_container.list,
div.state.edit_container.edit,
div.state.logout_container.logout {
  display:block;
}