Although nowadays we’re swamped with knowledge on more or less any topic we can imagine, it can still be hard sometimes to find reliable sources. In every industry, however, there is always a handful of individuals who really know their stuff and following their social media outlets, blogs, and their presence on other platforms is probably the best thing you can do for your career. In case you missed it, Karolina already drafted a similar list of Vue.js experts to watch in 2018. Now it’s time for Node.js.
Hey! If you have ever worked with Vue.js, Ember or MobX I’m pretty sure you stumbled upon so-called computed properties. They allow you to create functions that can be accessed just like normal values, but once computed they are cached until one of its dependencies has changed. In general this is a concept very similar to getters and in fact, the following implementation will be using getters. In a smart way. ;)
With the growing need for robust and interactive web interfaces, many developers have started embracing the reactive programming paradigm.
Before we begin implementing our own reactive engine, let’s quickly explain what reactive programming actually is. Wikipedia gives us a classic example of a reactive interface implementation – namely a spreadsheet. Defining a formula such as
=A1+B1 would update the cell whenever either
B1 change. Such a formula can be considered a computed value.
We have prepared a sample app with nothing more than the necessary configuration and a single, oversimplified spec file. You can find it on github now or first you can get more details about it below.
A couple of months ago Bartosz described how we use Facebook to improve communication in our team. Actually most of the content on our wall are more or less interesting links from the internet. We quickly noticed a troubling pattern though—they are easy to forget. And if you forget them, you can’t use them.
Currently at Monterail we're building a frontend-heavy app. With a lot of cool stuff. Like preloading data for daily views so that you won't have to wait for every surrounding day to load. Many, many interactive elements that should be really interactive - not in an oldschool, ajax
spinner way. And a lot of other stuff we shouldn't talk about yet.
As I wrote some time ago in the article about Rails, Ajax and jQuery, sometimes there are problems with Rails not interpreting correctly content type headers of ajax requests. It's because not all web browsers send that header in the same way.