Blog

Here we share our experiences, ideas, tips, and thoughts on React, Angular, Industry in general, and some other things.

Some of our latest posts: Malicious Dependencies · Tic-Tac-Toe Using Angular and MobX · Why do small frontend teams fail? · SVG in Angular 2 · The Definitive Guide to Choosing The Best JS Framework

Malicious Dependencies

3 Aug 2017  

Maayan Glikser

On August 1 npm was notified via twitter by Oscar Bolmsten that a package is maliciously stealing environment variables on install, using the popular cross-env package as bait by publishing a package similarly called as crossenv.

According to npm report further investigations revealed 40 packages in total using the same bait technique coined as “typo-squatting”.

What does this mean?

Environment variables are usually where application servers keep all their secrets such as database passwords, Amazon AWS access keys and much more sensitive data.

Because these packages often reach the production servers this can cause a hostile takeover to do anything the attacker wants, including spinning up new servers inducing large costs to the victims or gain access to databases and stealing users private data.

What do we do now?

First check the published list of malicious dependencies and check if your application or any of your dependencies are using any of the reported packages using npm ls in your application.

If you were affected you should reset all passwords and access tokens and removing the malicious packages.

How do we prevent this in the future?

While we can never guarantee malicious code entering our codebases via trusted and well known dependencies, we can continuously scan our applications for vulnerabilities using various services such as:
snyk, Node Security Project (NSP), BlackDuck or any similar services which monitor our dependencies and check for vulnerbilities.

These services can alert us sooner so we can minimize the damage done as soon as possible.

Why this isn’t enough?

This isn’t the first time npm was mentioned in the context of security issues. Just over a year ago npm experienced a meltdown when a package called left-pad got unpublished, causing many popular packages such as Babel and ReactNative to fail installing.

Following this Nicolás Bevacqua authored a post about the security implications of npm where many concerns were not addressed. The current state of npm packages requires us to establish trust in package authors and npm but many things can go wrong even if the package author did not intend to harm us.

A package author may get his account compromised, go rogue or make a mistake. Even worse, a package could be taken over by a new author using npm Dispute Resolution which could release new versions of the package without the end users even noticing.

There are no validations in place when a package was transferred to a new author, no indication to users that the author has changed and no mechanism in place to force a major version release so users will at least have a hint to look into what changed in the package.

While npm currently deals with the issue at hand, these repeating issues call for npm to take security more seriously and think on how they can minimize attacks in the future using their platform.

Subscribe to this blog
Share

Want the front-end experts to build your app? Contact 500Tech

Tic-Tac-Toe Using Angular and MobX

15 Mar 2017  

Adam Klein

MobX solves the problem of state management in frontend apps, in a declarative, simple and performant way. It differs from other popular solutions by removing a lot of boilerplate, and allowing you to work with mutable data and OOP.

The best way to explain how it works is via a code example.
Our demo application is a tic-tac-toe game.

Full code and demo.

The basic flow in MobX is:

  • observables – define trackable attributes
  • computed – define derived state
  • actions – change the state
  • reactions – react to the change (update UI)

Plain objects

A store in MobX is just an object. It saves only the minimal state of our application. In our case, a 3X3 array representing the board.

class Game {  
  @observable board:string[][];
}

The @observbale decorator tells MobX it should track access to the board attribute. Note that this has nothing to do with rxjs’ observable, except for the name.

Computed values

Tell me your board, and I shall tell you who the current player is...

In our example, we will need a few other attributes of the game.
For example, who the current player is, who is the winner, how many moves left, etc. All of these values can be derived from the board. In MobX, this is called computed values:


  // Count the total number of cells that have a value
  @computed get moves():number {
    return this.board[0].filter(cell => cell).length +
      this.board[1].filter(cell => cell).length +
      this.board[2].filter(cell => cell).length;
  };

  // If 'moves' is even, then it's X turn, otherwise O
  @computed get currentPlayer():string {
    return this.moves % 2 ? 'X' : 'O';
  }

Computed values are just declarative functions that calculate derived properties. They are only recalculated if needed, and if they are being observed somewhere.

Actions

Changing the state in MobX is simple. It’s simply setting attributes on plain objects:

@action play(i,j) {
  this.board[i][j] = this.currentPlayer;
}

@action resetGame() {
  ...
}

The @action decorator tells MobX to run this function in a transaction. A transaction is a block a of code that recalculates computed values only when the block finishes, and not immediately when observables are set.

Connecting to Angular

This is actually the easiest part.

1. Inject the store:

import { GameService } from 'app/services/game.service';

@Component({
  ...
})
export class ControlsComponent {  
  constructor(private game:GameService) { }
}

2. Use the store inside the component as a regular object:

template: `
    <div *mobxAutorun>
      <h1 *ngIf="game.winner">{{ game.winner }} has won the game</h1>
      <button (click)="game.resetGame()">Reset Game</button>
    </div>
  `

The mobx-angular library offers a *mobxAutorun directive that automatically observes the values that we use inside our template.

The ControlsComponent uses the winner computed value, and invokes the resetGame action. Whenever a board cell is changed, MobX will recalculate the winner attribute, and update the component – telling it to re-render.

  • If we use OnPush change detection strategy, we can gain extremely high performance.
  • When the component is destroyed, the observer is automatically disposed.
  • Under the hood, this directive uses MobX autorun function.

How does this magic work?

MobX wraps each @observable value with custom getters and setters. When we access this.board[0][1] for example, MobX adds this observable to a dependency tree of the current computed value. Then, when we run something like: this.board[0][1] = ‘X’, MobX checks the dependency tree and recalculates all the relevant computed values. Then, it runs all the reactions that are dependent on all observables and computed values that changed.

Where do I start?

A good place to start is to read mobx and mobx-angular documentation.

Then, create a POC on your existing app. Choose a specific page of the app and move the state to a MobX store to see how easy and straightforward it is.

Good luck!

Subscribe to this blog
Share

Want the front-end experts to build your app? Contact 500Tech

Quick Add React Component to Webstorm

15 Jul 2016  

Boris Dinkevich

One of the better practices in React is breaking our view to as many reusable components as possible. To make the test a bit easier, we can set WebStorm to auto generate React Component files.

Setup

  1. Open WebStorm
  2. Click Ctrl+Enter
  3. Select “Edit File Template”
  4. Click green + on left top
  5. Name it “React Component”
  6. Set extension to: “js” (or “jsx”)
  7. Click “enable live templates”
  8. Paste this to main edit view:
#set ($clean = ${StringUtils.sub(${NAME}, "_", "-")})
#set ($component = ${StringUtils.removeAndHump(${clean}, "-")})

const $component = () => (  
  #[[$END$]]#
);

export default $component;

Usage

Anywhere in WebStorm where file adding dialog pops-up (e. g. Ctrl+Enter) you can now select “React Component”

Set the name of the file (both “-” and “_” are supported) and viola – a new Dumb ReactJS ES2015 compatible component is created.

const HelloWorld = () => (  
  <h1>Hi</h1>
);

export default HelloWorld;

Summary

This is just a small taste of what WebStorm’s file creation and Live Templates can do. Do explore more.

Subscribe to this blog
Share

Want to be certain your front-end is done right? Contact 500Tech

Why do small frontend teams fail?

28 Apr 2016  

Boris Dinkevich

In the past few months, a week has not passed without me hearing of another company whose frontend project is late, broken, running way over budget, or just plain grotesquely underperforming. Are managers still unwilling to accept the nightmare that is frontend development in 2016?

First, the background

We run a small frontend consultancy, and apart from building products from scratch, we get called to help companies solve problems with their Angular or React code. Lately, the “problems” part has been growing and growing.

Every company we meet has performance problems, unmanageable code, missed milestones, and developers quitting left and right. Tests and CI? Heh. Half of them have never heard of build tools. Even among the few that appear to be releasing code, the dev managers admit that the only way to meet management’s milestones was to remove huge parts of the planned features.

What the hell is going on?

So we started asking questions and looking around. The surprising thing? It’s the larger companies that are doing fine. They have a clear separation between teams, and having a trained team(s) dedicated to frontend is the norm. It’s the small “agile” companies with 1-3 frontend devs that keep failing miserably.

These small teams usually consist of ex-server devs, just-out-of-school juniors, and a team lead that “has 30% free time and really wants to code.” In most cases they “learned as they went” and never had an experienced frontend developer to oversee the project and its setup and architecture, or provide mentoring. Worse yet, more than one dev manager has relied on a “frontend ninja” who (on closer inspection) turned out to be criminally clueless.

How did this work before?

We had a similar shift about 8 years ago when mobile came to our world, a new complicated technology with its own quirks and knowledge domain. So how are all those smaller companies managing to deal with native mobile? Out of all those companies with failing frontend projects we met, how many had a team of native mobile developers? Zero.

While the idea of taking a server-side Java developer and training him in a week to start building Angular applications seems fine, training the same developer to do Android development sounds ludicrous to management.

native is complicated and outside the scope of our existing expertise. Hell, we wouldn’t even know how to interview or train someone.

And yet, I bet in the office space next door you will find 2-3 developers slaving away on a huge Angular app with only a vague understanding of the “digest loop,” Webpack, Flexbox, or how to set up CI. Oh, and one of them probably spent the last 2 months writing a cool utility—that is available from a common NPM package.

What’s wrong?

Is it that frontend is harder than any other tech? Or maybe that it is as complicated as the others but doesn’t get treated as such?

It appears dev managers are roughly divisible into two groups: the proud and the sad.

The proud remember frontend from their developer days back in 2006. For them it’s a bunch of JavaScript and HTML thrown together in a few hours. Complicated build tools, large frameworks, and an endless amount of 3rd-party libraries are not something they are willing to accept as necessary or hard.

We literally argued with an R&D manager at a mid-sized startup who couldn’t understand why jQuery is not enough—“I built a complicated SPA in 2007 with nothing but jQuery.”

The sad know they are in a rut and don’t know how to fix it. They know that if it is taking 3 times as long to build and the app is still not ready, something must be off. Sadly, they find themselves in an impossible position:

  • “How can I hire a great frontend developer if no one here can interview and assess him?”
  • “We hired someone, but we don’t really know if he is good.”
  • “The really good people don’t want to work as a one-man-team alone.”

Self test

If you are thinking “we understand fully what frontend is and have none of these issues,” then ask yourself:

  • Is your frontend code sitting in the same repository as your backend code?
  • Is your iOS and Android code sitting there as well?

Did you say “Yes” to the first and “No” to the second? Time to ask yourself why.

What happens next?

Will it be months or years before missed deadlines and poor products convince management in smaller companies that frontend is not what it used to be?

When will they come to terms with the idea that frontend should be treated similarly to mobile apps—as a separate project and domain? Or understand that frontend is complicated, and requires a dedicated team of professionals and adequate time?

Until then, we’ll be left with uncomfortable meetings explaining why the Angular & jQuery beast the team has been building (as they learn) over the past 6 months (and that takes 30 seconds to load in Chrome on the latest MacBook) should be rewritten in React in 2 months. If only they’d stop and properly train their team.

Viva la frontend!

Comments on HN

Subscribe to this blog
Share

Looking for front-end consulting? Contact 500Tech

Earlier Ctrl + ↓