I know, I know. This title sounds cocky, but in fact it makes a lot of sense if you think about it. I’ve been asked multiple times by my friends from our local React meetup group I’m organizing or by teams I’m helping to develop their applications for a starter, boilerplate or setup. This post is actually a result of another such question. It’s always one of the two scenarios.
devBlog of Michal Zalecki
If you working on web services for some time you probably remember, or at least heard about, The First Browser War. We are extremely lucky that this scramble between Internet Explorer and Netscape turned into great race for better, faster, more unified web experience. That said, we still facing a lot of inconsistency or not trivial edge cases while working with so-called browser APIs.
React components went the long way from
React.createClass through ES2015 powered
React.PureComponent and stateless functional components. I really enjoy the idea that we don’t
have to “hack” the language anymore, at least not that much as we used to. The progress in this
department is quite clear and brings not always obvious benefits. Using constructs build into to the
language/transpiler instead of relying on framework’s factory functions or constructors accepting
huge configuration objects future proofs your code.
Heroku managed to significantly lower the bar when it comes to deploying applications and integrating them with third-parties through various add-ons. It can be argued, but in my opinion optimizing platform to be easy at the entry-level made it much harder to do some more advanced setups. It’s strange but for quite a long time of using Heroku and feeling comfortable with it I’ve never had to configure it from A to Z. I was treating Heroku as some kind of rapid prototyping environment and finally migrating it to more dedicated solutions. That said, for one of the projects Heroku turned out to be a great fit and it made sense to keep it that way. So, now I only have to set up a root domain.
Automated browser tests, in my case, are often part of continuous integration (CI). Failure = no deploy. This naturally creates some expectations towards acceptance/end to end testing framework. I haven’t found the tool which would meet all requirements although CodeceptJS is close. Nevertheless, no matter whether you use Protractor, Nightwatch.js, WebdriverIO, CodeceptJS or anything else based on Selenium you need to set it up and make it talk to the browser.
My first offline web app heavily depended on AppCache and it was painful experience. Don’t get me wrong, AppCache initially blow my mind, in a positive sense. Web App without a web? In the browser? Sounds awesome, isn’t it? My further experiments with AppCache convinced me that unfortunately it’s not the path I’d like to follow when it comes to building something serious.
We are designing our applications for better separation and many patterns evolved from that effort. It’s not any different in case of projects I have done. There were couple architectures along the way and tries to simplify all of the building block no matter whether it was MVC, MVVM, Flux, Redux and so on. The glue for all of those elements is data. At the end of the day everything operates or consumes data. When you make your data model flat and decoupled form API you gain full control over modeling you application state.
Pure functions are functions which for certain input always returns the same output without modifying its surroundings. So, they are free from side effects. Because of that feature they are easy to test and highly reliable part of your system. Why only a part? There is a lot of different side effects and it’s more probably than not that your app is full of them. Every DOM mutation, API request, pushState or even console.log is a side effect. It’s hard to imagine an useful application without side effects.