Dropzone.js, React.js and Fluxxor integration

Introduction In these days I’m digging deep in the wonderful React.js library, widely used by Facebook and Instagram for their UIs. This library uses an abstraction of the DOM, called Virtual DOM, to render components in the View. Honestly ~~I’m~~ was not a big fan of DOM abstractions, because in my opinon it affects both the work of developers and designers. HTML should not be mixed with JavaScript and viceversa. I’ve worked in the past years with declarative libraries like Knockout.js, so at first I was disoriented by this new approach. However after spending a couple of days on the docs I was really blown away by the power and the intuitiveness of the library. By the way, take a look at this blog post by Pete Hunt which presents a clear approach to start thinking in React. React.js “makes no assumptions about the rest of the technology stack”, therefore...

Read More
Durandal 2.0 folder structure and optimization

Folder Structure Recently, before starting a Node.js (using Locomotive.js) and Durandal project, I searched the web for the optimal folder structure. I didn’t found nothing really useful so I decided to go on using the Durandal’s convention, separating views and viewmodels, in the public folder of the Node.js application. I ended up using the following structure: App: the main folder of the Durandal application views: HTML files of the application (V in MVC) viewmodels: the business code of the application (C in MVC) dataservices: functions that interact with the REST endpoints on the Node.js server, returning promises for the controllers models: client-side models (M in MVC), a sort of replication of the entities used on server side, populated using the data from the dataservices datacontext: middle-layer between dataservices and the business code. It’s used to cache the data, for faster access by different parts of the application. Think it as...

Read More
JavaScript Closures

Introduction In this new post I’m going to talk about “closures”. Just like hoisting, closures are a key concept to JavaScript, since they allow to create functions that bind the variables within a scope. Closures are usually used to build callback functions. A good definition is available on the Mozilla Developers Network website, on which this post is entirely based. Closures are functions that refer to independent (free) variables. In other words, the function defined in the closure ‘remembers’ the environment in which it was created. Let’s start with a first example, to better understand what we are talking about: function init() { var name = "Foo"; function nowDisplay() { alert(name); } nowDisplay(); } init(); The init() function creates a new local variable called name and defines an internal function called nowDisplay. This function has visibility on the variable declared and initialized in the outside function. The code is really...

Read More
JavaScript Hoisting

Introduction In this post I am going to talk about JavaScript. Recently I rediscovered this programming language, after a long time distance caused mainly by its quirks. However while working on my thesis I started to enjoy this language and I realized how much powerful it can be, if used in the correct way. “Do you want to work with the Web? Better learn JavaScript” said once a teacher of mine. Therefore with a series of posts I’m going to analyze those little irregularities that make JavaScript less intuitive, providing endless arguments to the people that hates it. Mastering these inconsistencies distinguish the experienced programmer with the newbie. Note: the article assumes some basic experience in JavaScript from the reader. Variable Hoisting Let’s start talking about “hoisting”. There are a couple of premises before diggin in the code. I’m assuming that you know the difference between declaration and initialization of...

Read More