I’ve been working on this article for a month, off and on. When I started, I set out to demonstrate the performance impact of change detection in Angular. In particular, I wanted to demonstrate that turning zones off would have a significant impact on performance even if you followed all my other advice regarding performance optimization.
That is, if you had:
As I’ve considered all the issues I’ve seen over the years and, as I’ve talked with and interviewed with other developers, I’ve come to the conclusion that our industry has two main problems. Fix these and all the other issues we face will solve themselves.
If you’ve been using some form of Redux, you are familiar with the basic flow of data through the Redux loop. Central to this flow are Actions, the messages that trigger code in our Reducer or Effect/Epic/Saga (depending on what flavor of Redux you are using).
The model allows us to disconnect our code so that it only cares that an action was triggered in some way. That is, “when this action occurs, I will run this code.”
Because of this, we can create an action that triggers multiple code blocks to run. Our only concern is that the code that gets triggered can’t depend on each other.
In fact, much of the official literature encourages this practice.
And, this is where all our troubles begin.
In my previous article about Angular Performance, I indicated that one of the many ways you can produce an Angular application that performs well is by ensuring that you bind to a computed value.
First, what did I mean by that?
The temptation, when using RxJS is to include conditional logic inside your map, tap, or subscribe blocks. But there is a much better way to deal with conditional logic that will make your code much easier to read and reason about. It also should make your code easier to test. But of course, once you have code that is easy to test, you probably no longer need to test it.
The Single Responsibility principle is a well-known, Object Oriented principle that states that we should narrow the scope of the code in our Module/Class/Function so that is it only responsible for one thing.
By doing so, this reduces the size of our code that needs to be tested.
Linting rules can generally help enforce this rule by making sure your Class file isn’t too long, and your functions are not too complex. But there are other ways of violating this principle that linting rules can not pick up.
I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry.
Actually, I’m STILL frustrated. I originally wrote this article January 2015. Not only is it still true. It is more true.
Our industry has been treating Scrum and Agile as “buzzwords that mean nothing.” These words get slapped onto job requirements like the typical requirements we’ve all seen.
What’s really funny is when I see
together in the same job request.
And even if it doesn’t show up in the job description. Once you get into the organization, you find out they are no different than any other organization. All those promises about running “Agile” or “Scrum” as a well of figuring out how long a project will take fly right out the window as soon as a manager wants something done by a specific date.
If management ain’t Agile, ain’t no one Agile.
The purpose of this article is to specify a working architecture that everyone can use for any Angular applications. This architecture aims to achieve the following goals:
I recently read (yet another) post proposing that TDD “doesn’t work” and that we shouldn’t use it, or should use it very little. What was shocking about this article wasn’t the content, but the fact that it is hosted on a Microsoft site.
While I’m not entirely on board with throwing out TDD, the one thing I will agree to is that learning TDD is difficult. I am also willing to admit that, to a large extent, TDD is broken. If you’ve been following my post for a while, this SHOULD be shocking news.
And so, I’ve been thinking.
Maybe we’ve been asking the wrong question. Maybe, instead of asking “How do we encourage people to implement TDD?” We should be asking, “How do we make TDD either unnecessary, or trivial to implement?”
As I was sharing my LinkedIn tips with a co-worker this past week that made me realize that I’ve accumulated an incredible amount of knowledge about using LinkedIn that I should probably share. Things that aren’t obvious to the typical user.
But first, I have to ask a question.