Geofencing allows for locating points within defined geographic areas. Areas can be defined with geographic points, consisting of latitude and longitude, forming any shape. HERE provides Geofencing Extension API for that purpose.
I know, I know. This title sounds cocky. 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 a setup. This post is a result of another such question. Most of the time it’s one of the two scenarios.
If you are 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 a great race for better, faster, more unified web experience. That said, we’re 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.
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.
At first sight, RxJS is blown up lodash but for dealing also with async. In reality, it’s so much more than that. With a few simple operators, you can implement a Redux-like state machine, schedule animation or deal with any type of events no matter whether it’s WebSocket message or filling in the text input.
On 16th December I had a pleasure to give the presentation about Flux architecture pattern on ReactJS Wrocław meetup. Flux is well known in React community and has many different implementations not without reason. After short introduction I pointed out 7 common problems and compered how different implementations are trying to solve them.
When your SPA is growing its download time is getting longer and longer. That’s not going hand in hand with better user experience (remainder: that’s why we are doing SPAs). More code means bigger files and when minification isn’t enough for you the only thing you can do for your user is stop making him to download whole app at once. Here lazy loading comes in handy. Instead downloading every file let your user download only files which he need NOW, at this very page.
ECMAScript 6 (also known as ECMAScript 2015) is the new, but not the newest (ECMAScript 7), version of ECMAScript standard and it’s based on ECMAScript 5.1. Since August 2014, ES6 is feature frozen. After publication process which will start in March 2015, ES6 will be finished in June 2015. Despite that ES6 is not finished yet there aren’t any good reasons to not use it today thanks to great tools like Traceur from Google or Babel. ES6 is solving many real-life problems which, as programmers, we are facing on a daily basis not only in browsers but also on the server side.