Over the last couple of weeks, I’ve mentioned that I’ve been learning React JS. First in the article “Reaction to React JS and Associated Bits” and then last week in my article “Test Driven Learning”. In the first article, I mentioned that if you use React JS, you’ll probably end up using the Flux design pattern and since there are multiple ways of implementing flux, getting a clear definition of what it is and how it should work can be confusing. At least, I found it confusing.
And now that I’ve figured it out, I thought it might be helpful both to myself and to the programming community at large if I offered my own Explanation of the Flux Pattern. At the very least, it will give me one more way of solidifying the concept in my own brain. Maybe it will be helpful to you as well.
As I mentioned last week, I’ve been learning React JS over the last month or so. Up until the start of this project, I would learn a new framework, and then I would try to paste in Test Driven Development after the fact. I would use the excuse that because I didn’t know the framework well enough, I wouldn’t be able to properly write tests for it.
But this time, I decided to do something different. What if I wrote tests for my demo application as I was learning this new framework? My reasoning was that learning how to test code written in the framework was just as important as learning the framework.
What follows are the lessons I learned from this wildly successful experiment.
This is an important distinction. In a strongly typed system, we can say that a member of our object is a property or method simply because it was defined as one or the other when we defined our class.