We know the grisly mess that asynchronous programming causes!

If we aren’t deep in spaghetti call-backs then we are trying to swat a promise!

We learn why JavaScript forces unstable and tightly coupled testing architectures when using only callbacks, promises or async and await.

Instead, we learn to manually create and then leverage the observer pattern to gain fine grain control of our app state and therefore get TOTAL control over the Single Page App, and that means your TESTS become easy to READ and WRITE.

Now you have the requisite architecture knowledge, it’s time to write your first simple test.

But unless you have a repeatable pattern for making your test call your production code in EXACTLY the same way as the PRODUCTION code does, your tests are WORTHLESS.

Luckily in this module we learn the control patterns to fully control our app that so that it will load data and track state. Then we leverage the power of ‘black box’ design and test doubles to setup a clean, and clear System Under Test (SUT).

How DO we test COMPLEX app events such as user actions, API responses and application transitions in a single test?

We take principles from the last module and learn how to create consistent test code. This can then layer all of our app events in successive steps which we control without our tests becoming fragmented.

In this lesson we will learn how to build our complex tests meaning no matter the requirement that the suits from the business hand you, you can test it like a BOSS!

In modules 7-12 of the training we further advance your knowledge and show you the architectural rules and software design theory that will let you scale up your UI app to any size.

Do you find yourself spending too much time wrestling with React props? Got way too many complex objects in Redux? or perhaps you end up always fighting with Angular directives?

You could have... a presentation problem!

Left unchecked a UI app subtly buries too much information in the markup of your chosen UI framework. This week is going to blow-the-lid off this simple rule; good architecture starts with good presentation.

In this module we learn the fundamental difference between hierarchical data models and flat models, and how we can detect and fix bad views through the power of better presentation architecture.

In this module we will;

Let's face it, with all the hot air about software architecture why does nobody ever give us the ONE rule which makes all the difference?

In this module you will learn what that ONE most important rule in a UI app is! By discovering how an engineer cannot ‘see’ architecture unless they can 'control' it!

We do this by taking what we learned in the last module and creating 'breathing space' in our architecture. Then we can centralise a conceptual model which is designed to let us ‘think’. Trust me, if there is one thing you want to get better at when you are building architecture it's THINK, so...

In this module we will;

Whats your biggest fear in a JavaScript UI app? Let me guess. Is it being FORCED to use ES5? Perhaps you need to support IE10 still? {Giggle}, no, no, NO, the true ENEMY at the gates in a JavaScript UI app is... UNWANTED side-effects!

We do NOT want our UI apps to behave unpredictably and start throwing out data in odd situations or at the wrong time. Because apart from being stressful it also makes testing near on... __impossible__!

We are going to shine a SPOTLIGHT right on this issue. Side-effects in a JavaScript UI app are caused by two categories of problem; timing and encapsulation. It's these two things which give rise to BRITTLE behaviour, odd side effects and unhappy engineers who can't keep control!

We will learn to leverage the paradigm of functional reactive architecture to cleanly solve both timing AND encapsulation issues properly. We are going to show you how to force a 'one-way' data flow on your app but without using a sea of complex tools. We will demonstrate to you the simplest way using the lightweight MOBX framework (but you can use any other FRP framework once you learn the rules).

So, in this module we go deep on the following;

If you have been shipping UI apps for more than a few years you will have seen the dizzying array of ways that module dependency loading works. Dependency loading is critical to a UI app, but the normal module loading tools do not give us the flexibility we need to SCALE because we are not in 'control' of the lifecycle.

We need control because often our dependencies are hard to test and hard to extend. For this reason we must have a way to centralise and dynamically load some of them. This will enable more flexible and testable code.

Learning all the subtle differences between the sub-topics of Dependency Inversion, Dependency Injection and Inversion of Control will enable you to confidently apply dependency management in your UI apps.

So, this module takes you deep into;

Do you dream of being able to create a multi-level, location aware, and configurable navigation menu and sub-menu-system, driven by simple JSON that works on both desktop AND mobile screens WITHOUT having to duplicate HTML?

No?

Me NEITHER!

Pssst, only JOKING 😃

That's exactly the sort of power I want in my UI apps!

If THIS is the sort of power you also crave, then don't fear this module... ABSTRACTIONS is what you need!

Everything you have learned so far has been helping you connect up the major architectural concepts in your UI app confidently. But you are going to need to manage some 'cross-cutting' concerns too. For example there are common features that almost every UI app needs; such as routing, navigation and 3rd party controls.

At best engineers tightly couple these concerns to the wrong places using the wrong interfaces. At worst they don't even have a design which defines them in the first place! They just bury these subtle but HIGHLY important abstractions in all the other parts of their app, like in-the-markup, noooo....

So, in this module we teach you how to interface your highly scalable UI architecture to all the cross cutting concerns. We do this by ABSTRACTING them into clear and unambiguous patterns that... WORK. We are going to tear apart your very real integration concerns that you WILL encounter in the wild, we cover;

By this point in the academy you have now learned all of the foundation and critical knowledge you are going to need to confidently tackle and architect complex UI apps!

But your work isn't done until you have completed a 'final project' where you will holistically cement the knowledge you have learned so far! We have designed this final project to give you exposure to all the interlocking concepts you need.

In this module we will complete the 'Books and Authors' sample app by going through 4 stages together and building it one stage at a time.

Anyone who has ever trained with us will tell you we are different to most coaching companies because we do not claim to be ‘Gurus’.

Instead we teach simple ways of doing complex work that are not based on theory, they are based on the battle tested experience of real projects that our company does commercially!

Yes, that’s right.

Myself and my team use these techniques that I teach on actual live projects for companies that we consult with.

This means that you are not gaining information which is based on subjective opinion but on the hard-learned lessons of commercial reality and real case-studies.

This means our training is simpler because we don’t have time to teach our clients pointless theory when they have actual deadlines to hit.

This means you get results first not theory.