Category: JavaScript

An elegant solution for handling errors in Express

Express is a microframework that according to 2018 Node.js User Survey Report is used by 4 in 5 back-end and full-stack node.js developers. Thanks to its simplicity, the always-growing range of available middleware, and active community the express userbase is still growing.

Solve code sharing and setup project with Lerna and monorepo

Code sharing is easy but doing it correctly is challenging. There are multiple ways you can do it, and your use case dictates what approach is right for you. The low hanging fruit is just copy-paste what you need from StackOverflow, GitHub, or your previous project. Despite the apparent benefit of being the most natural, copying and pasting wastes your time in the long run due to causing the maintenance burden of syncing changes manually.

Integration tests with web3, Ganache CLI and Jest

Well written set of tests plays a crucial role in delivering a reliable software. A good test suit ensures that the application works as intended and significantly reduces the number of bugs. It’s easier said than done. One of the steps to achieve this goal is adhering to boundaries of different test levels. In this article, I want to focus on the integration testing of decentralized applications that rely on web3. For integration testing, I’m able to sacrifice the speed of execution to gain the confidence that different components of the app seamlessly work together.

An Intro to Nebulas for Ethereum Developers

Nebulas is yet another platform on which you can develop smart contracts. It offers a means of using JavaScript to develop Smart Contracts — an intriguing alternative to more established solutions, such as Ethereum.

Integration tests and mocking web3 apps

Decentralized applications present a new set of challenges. One of them is testing. Transaction lifecycle is more complex than the old-school POST request/response flow and errors are often less than helpful. Although developer experience is getting better, this puts into perspective how testing is essential.

Nominal typing techniques in TypeScript

Many functional programming languages like Haskell or Elm have a structural type system. This perfectly lines in with the direction in which majority of JavaScript’ish community is heading. Nevertheless, every feature comes with a certain set of trade-offs. Choosing structural type system allows for a greater flexibility but leaves a room for a certain class of bugs. What I find interesting is that the answer to the question whether TypeScript, Flow or any other type system adopts structural or nominal type system does not have to be binary. So, is it possible to have the best of both worlds writing in TypeScript?

Testing redux-thunk like you always want it

Redux Thunk is one of the most if not the most popular Redux middleware with over 2 million downloads a month. If you compare this number to the Redux 4 million downloads a month, it is easy to figure out that over half of Redux projects are using Redux Thunk. As the name “thunk” suggests, the main goal of Redux Tunk is to allow for lazy evaluation (dispatching) of actions. While this makes it possible to dispatch actions in an asynchronous manner, it also makes it harder to test.

Fixtures, the way to manage sample and test data

Fixtures are a thin abstraction layer over sample data in your application which allows for better organizing, often complex, data structures representing different entities. If this sounds like a vague description or does not ring the bell maybe an example will speak to you better.

Render React portals on the server

React works, in what I would call, homogeneous manner. A tree of components is going to be rendered in the given component using a render or recently introduced hydrate function. You are not supposed to change DOM elements created by React or at least do not change components which can return true from shouldComponentUpdate. But what if you need to change an element outside of the React realm? Well, portals are the way to go!

Writing clean code with memoized event handlers

When we talk about writing asynchronous JavaScript we often use timer functions or promises as an example. Whereas the majority of asynchronous code written in modern JavaScript web apps is focused on events caused either by a user interacting with the UI (addEventListener) or some native API (IndexedDB, WebSocket, ServiceWorker). With modern front-end frameworks and the way we pass event handlers it is easy to end up with leaky abstraction.

Optimize React build for production with webpack

This guide is a form of writing down few techniques that I have been using with ups and downs for the past two years. Optimizations highly depend on your goals, how users are experiencing your app, whether you care more about time to interactive or overall size. It should not come as a surprise, that like always, there is no silver bullet. Consider yourself warned. Although you have to optimize for your use cases, there is a set of common methods and rules to follow. Those rules are a great starting point to make your build lighter and faster.

Implementing Geofencing with HERE

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.

The Best React Boilerplate: DIY

I know, I know. This title sounds cocky. In fact, it makes a lot of sense if you think about it. I have been asked multiple times by my friends from our local React meetup group I am organizing or by teams I am 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 is one of the two scenarios.

Why using localStorage directly is a bad idea

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 and class properties

React components went the long way from React.createClass through ES2015 powered React.Component to 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 built into the language/transpiler instead of relying on framework’s factory functions or constructors accepting huge configuration objects future proofs your code.

Why I use double quotes in JavaScript

Coding style is often a topic of fierce debates, mostly unnecessary. What matters is being consistent throughout the project, or better, your entire codebase. Tools like JSHint, JSCS and ESLint contribute and popularized advantages which come from keeping code style consistent. I’m used to airbnb/javascript style guide with couple exceptions and this post justify my decision to go for double quotes in our entire JavaScript codebase.

Progressive Web Apps with Webpack

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.

TypeScript vs Flow

TypeScript calls itself a JavaScript superset and compiler while Flow is a static type checker. TypeScript is developed by Microsoft and highly inspired by C# or Java type systems. What I find interesting is that TypeScript is actually written in TypeScript. Flow is created by Facebook, written in OCaml. Most TypeScript annotations are compatible also with Flow so learning curve for switching from one to another is really smooth.

Simplifying data with object mappers

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.

Reduce side effects in React/Redux

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.

Use RxJS with React

At first sight, RxJS is blown up lodash but for dealing also with async. In reality, it is 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 is WebSocket message or filling in the text input.

RxJS and Cycle.js

I gave the presentation on Warsaw and Wrocław meet.js meetups about RxJS and Cycle.js. Until the same meetup I had doubts whether live coding is the best way to introduce the audience in the topic of reactive programming in JavaScript. Apparently it went way beyond my expectations. I got many questions both in Wrocław and Warsaw and really positive feedback!

The problem of Flux

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.

Lazy load AngularJS with Webpack

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 Overview

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.

This website uses cookies. Continuing to use this website gives consent to cookies being used. You can disable them in your browser's settings.