Forem: Martin Garcia

Check for undefined in JavaScript

Martin Garcia — Sun, 03 May 2020 00:00:00 +0000

If you’re writing JavaScript more or less regularly, at some point you’re probably faced with a situation where there was a need to check if a variable is undefined.

But, what is the best way to do it?

The intuitive way

Any programer with experience in other language will use the intuition to figure out:

if (x === undefined) { ... }

And this will work without any problem, or almost.

Comparing directly with undefined will work on all modern browsers. But old browsers allowed its value to be re-assigned like this:

undefined = 'new value';

With this re-assignment, a direct computation will not work as expected.

This behavior was fixed in 2009 with ECMAScript 5 :

15.1.1.3 undefined

The value of undefined is undefined (see 8.1). This property has the attributes { [[Writable]]: false , [[Enumerable]]: false , [[Configurable]]: false }.

The “safe” way

If you have to support old browsers and you’re concerned about someone re-assigning the value of undefined there are other ways to do the check.

Reading the type

You can use the typeof operator, that will return the string "undefined" so you can check for it.

if (typeof x === "undefined") { ... }

Note: The typeof operator does not throw an error if the variable has not been declared.

Using `void`

Alternatively, you can use the typeof operator to check for undefined. For example:

if (x === void(0)) { ... }

In this example, the zero doesn’t have any special meaning. As stated on MDN:

The void operator evaluates the given expression and then returns undefined.

Which way is better

In my time as a consultant I learned what’s the best answer for this kind of question: it depends. I would depend on the concrete use case you have but I can give you some tips.

In general, I tend to use the convention that is already present on the codebase. But if you’re writing a new code that will run only on modern browsers I’ll suggest to go for the direct comparison (it’s clear and easy to understand also for people that don’t know JavaScript). For old browsers support, I strongly recommend to create a function isUndefined and use the option of your choice inside. Then the code will express their purpose clearly to everyone.

(This is an article posted to my blog at magarcia.io. You can read it online by clicking here.)

The power of MVP

Martin Garcia — Wed, 29 Jan 2020 00:00:00 +0000

There is a lot of literacy about minimum viable products (MVP) everywhere. I don’t think I could bring to the field more information or value that the one that already exists but I’ll give my point of view on it based on an experience I had working with one client.

A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.

Wikipedia

Let’s start putting this article into context. The client was a leading European company in the real estate field, although I don’t think the domain matters in this case, and the product team had an idea of a quite complex product they want to sell to his customers. In order to know the acceptance by the website users, we run multiple A/B tests to see which was the most successful approach. The product itself was no that complex to implement but the decision of which users should see what, that was another story. We had to take into account the location of the user, in which location was searching, the last visit to the page, etc. The number of values that we had to play with was big, so in order to have enough valuable data to make the proper decision, we ran the tests for almost half a year.

This kind of experiment doesn’t make sense without proper metrics, so we measured everything. Once the test finished, the data analysis team did his job and turns out the values were not the expected ones, neither close to it. Turns out not everything was that bad. One small part of the product had a really good acceptance between users, and one month later the product team came up with a different product based on this small part.

After this, not that small introduction, is where this story begins. This new product did not have the complex rules of the previous one: no location related, neither user visits or search history. The customers will have a special section on the page to show their products and they could share how they prefer with their clients. Now that we had the product (the user-facing part was already implemented for the previous test) was time to make it real and start selling it.

One day we had the meeting to define the architecture and how we were going to do it. The two engineering teams involved, the head of technology and the product owner. Around 14 people in the room (actually virtual rooms since teams were distributed in different countries) discussing what was going to be the best way to implement it and trying to guess when was going to be ready. Someone said because the product needs to be bought by customers we should talk soon or later with the engineering team in charge of this area. The team in charge of the products will have to create a new microservice to handle the new product and the one in charge of the website will have to consume and process this data in order to enable or not the product for a given customer.

All together start to look complex again, first guesses of when it would be done were at least three months, but probably more since it would involve coordination with multiple engineering teams, marketing, design, etc. Listening to all the discussions happening the lazy part of my brain got activated and I asked a key question to the product owner: “How is this product going to be addressed to the customers in order to sell it in the short term?”. The answer was the key to find a more easy way to solve this problem. Only a small group of people in the sales team will contact the most important customers to sell the product, at least initially; and after that, they will evaluate which other customers would be interested.

With this new information, I proposed an unorthodox approach for the implementation. Instead of building the complex system, coordinate multiple teams and block the launch until everything is done; why not hardcode the customer id’s on the code and have just a couple of lines to handle the logic. Every time the product sold to a customer, someone just has to send an email to the team and we could add the id in minutes. This, obviously, is not a solution that scales but is not the intention. Since the sales were going to be “manually” at the beginning we can expect the pace of which customers will acquire the product will be controlled.

The proposal I made was actually well received by everyone, this will allow us to start selling earlier and will relieve the pressure on the engineering teams to build the final solution. In just one week we were having the product in place and sold to the first customer. The next months the teams were more relaxed working on the final implementation that will not involve manual interactions anymore.

So, this was the story I want to share. I don’t know if it would be useful for you but at least I learned some important points:

Keep the implementation as simple as possible, you not only will reach the marked earlier probably you could remove or relax some deadlines.
Engineering teams should be involved as early as possible on the product definition because different points of view can find a better solution.
The whole vision of the project should be shared with engineers, not only the part they have to work on since it helps to decide the architecture.

In conclusion, I’m going to keep doing one of the things I consider most important in a developer: being lazy. Because this attitude will help me to find the most easier and fastest way to solve a problem.

(This is an article posted to my blog at magarcia.io. You can read it online by clicking here.)

SOLID — Principles of Object-Oriented Design

Martin Garcia — Sat, 07 Dec 2019 20:23:20 +0000

SOLID Principles are a valuable tool to write good object-oriented software. This article tries to put some light on the subject with simple explanations and examples for each principle using TypeScript.

This article is based on the work done by Samuel Oloruntoba in his article S.O.L.I.D: The First 5 Principles of Object Oriented Design but using TypeScript instead of PHP for the examples.

SOLID is an acronym for the first five principles of the article Principles of Object-Oriented Design by Robert C. Martin.

Applying these principles helps to develop maintainable and extensible code. They also help to catch code smells, refactor code easily, and practice a good agile development.

S stands for SRP — Single Responsibility Principle
O stands for OCP — Open-Closed Principle
L stands for LSP — Liskov Substitution Principle
I stands for ISP — Interface Segregation Principle
D stands for DIP — Dependency Inversion Principle

SRP — Single Responsibility Principle

A software entity (classes, modules, functions, etc.) should have one, and only one, reason to change.

This principle means that an entity should do only one thing. So single responsibility denotes some work in isolation. Therefore if we have a software entity that performs some calculations the only reason to change it is if these calculations need to change.

In order to understand better the principle, we can do an example. Let’s say that we have to implement an application that given some shapes it calculates the sum of the area of these shapes and prints the output.

We start creating our shapes classes:

class Circle {
 public readonly radius: number;

 constructor(radius: number) {
 this.radius = radius;
 }
}

class Square {
 public readonly side: number;

 constructor(side: number) {
 this.side = side;
 }
}

Now we create an AreaCalculator class that is going to have the logic to sum the area of our shapes.

class AreaCalculator {
 public readonly shapes: Shape[];

 constructor(shapes: Shape[]) {
 this.shapes = shapes;
 }

 public sum(): number {
 // logic to sum the areas
 }

 public output(): string {
 return `Sum of the areas of provided shapes: ${this.sum()}`
 }

To use the AreaCalculator we have to create an array of shapes, instantiate the class and show the output.

const shapes: any[] = [new Circle(2), new Circle(3), new Square(5)];

const areas = new AreaCalculator(shapes);

console.log(areas.output());

But this implementation has a problem. In this example, AreaCalculator handles the logic to calculate the sum of the areas AND to output the data. What if the user wants the output in JSON?

Here is when Single Responsibility Principle comes into play. AreaCalculator should only change if we change how we calculate the sum of the areas, not when we want a different output or representation.

We can fix this by implementing a class which its only responsibility is to output the data.

const shapes: any[] = [new Circle(2), new Circle(3), new Square(5)];

const areas = new AreaCalculator(shapes);
const output = new Outputter(areas);

console.log(output.text());
console.log(output.json());

Now we have two classes with one responsibility each one, if we want to change how calculations are made only AreaCalculator will change and the same to change the output, it will affect only Outputter.

OCP — Open-Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

A desirable property that our software entities is to be easy to extend his functionality without the need to change the entity itself.

Using the previous example, now we want to introduce a new fancy shape: the Triangle. But first, take a closer look at the sum part of our AreaCalculator class.

class AreaCalculator {
 public readonly shapes: Shape[];

 constructor(shapes: Shape[]) {
 this.shapes = shapes;
 }

 public sum() {
 let sum: number = 0;

 for (let shape of this.shapes) {
 if (shape instanceof Circle) {
 sum += Math.PI \* Math.pow(shape.radius, 2);
 } else if (shape instanceof Square) {
 sum += shape.side \* shape.side;
 }
 }

 return sum;
 }
}

Here we are violating the Open/Close Principle, because in order to add support for triangles we have to modify AreaCalculator adding a new else if block in order to handle the calculation of the new area.

To fix this we can move the code that calculates the area to the corresponding shapes, and make that shapes implement an interface that describes better what a shape can do.

interface Shape {
 area(): number;
}

class Circle implements Shape {
 public readonly radius: number;

 constructor(radius: number) {
 this.radius = radius;
 }

 public area(): number {
 return Math.PI \* Math.pow(this.radius, 2);
 }
}

Now the AreaCalculator looks like the code below, that allows us to create new kind of shapes and it will work always that this new shape implements the Shape interface.

class AreaCalculator {
 public readonly shapes: Shape[];

 constructor(shapes: Shape[]) {
 this.shapes = shapes;
 }

 public sum(): number {
 let sum: number = 0;

 for (let shape of this.shapes) {
 sum += shape.area();
 }

 return sum;
 }
}

LSP — Liskov Substitution Principle

Derived class must be substitutable for their base class.

What this principle means is that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. So if you pass a subclass of an abstraction you need to make sure you don’t alter any behavior or state semantics of the parent abstraction.

Continuing with the AreaCalculator class, now we want to create a VolumeCalculator class that extends AreaCalculator:

class VolumeCalculator extends AreaCalculator {
 public readonly shapes: Shape[];

 constructor(shapes: Shape[]) {
 this.shapes = shapes;
 }

 public sum(): number[] {
 // logic to calculate the volumes and then return
 // and array of output
 }
}

To understand better this example let’s make a more detailed version of the Outputter class.

class Outputer {

 private calculator;

 constructor(calculator: AreaCalculator) {
 this.calculator = calculator;
 }

 public json(): string {
 return JSON.stringify({
 sum: this.calculator.sum();
 })
 }

 public text(): string {
 return `Sum of provided shapes: ${this.calculator.sum()}`;
 }
}

If we try to run a code like this:

const areas = new AreaCalculator(shapes2D);
const volumes = new VolumeCalculator(shapes3D);

console.log('Areas - ', new Ouputter(areas).text());
console.log('Volumes - ', new Ouputter(volumes).text());

The program is not gonna fail but the output will not be consistent since one output will be something like Areas - Sum of provided shapes: 42, and the other Volumes - Sum of provided shapes: 13, 15, 14. This is not what we expect from our program.

This happens because the violation of the Liskov Substitution Principle, the sum method of the VolumeCalculator class is an array of numbers while the AreaCalculator is just a number.

To fix this we have to reimplement the sum method of VolumeCalculator to return a number instead of an array.

class VolumeCalculator extends AreaCalculator {

 // constructor

 public function sum(): number {
 // logic to calculate the volumes and then return
 // and array of output
 return sum;
 }
}

ISP — Interface Segregation Principle

Make fine grained interfaces that are client specific.

In this case, we want to keep interfaces as small as possible, so clients are not forced to implement methods that they don’t actually need.

So, coming back to our shape interface, now that we can calculate volumes our interface looks similar to this:

interface Shape {
 area(): number;
 volume(): number;
}

But we know that not all our shapes have a volume, Square is a 2D shape but because of the interface, we are forced to implement a volume method.

Applying the Interface Segregation Principle we split the Shape interface into two different interfaces, one to define 2D shapes and another for 3D shapes.

interface Shape2D {
 area(): number;
}

interface Shape3D {
 volume(): number;
}

class Cuboid implements Shape2D, Shape3D {
 public area(): number {
 // calculate the surface area of the cuboid
 }

 public volume(): number {
 // calculate the volume of the cuboid
 }
}

DIP — Dependency Inversion Principle

Depend on abstractions, not on concretions.

What this principle comes to says is that high-level modules should not depend on low-level modules, but they should depend on abstractions.

This principle allows for decoupling, an example that seems like the best way to explain this principle. Let’s see a new class to save our shapes ShapeManager:

class ShapeManager {
 private database;

 constructor(database: MySQL) {
 this.database = database;
 }

 public load(name: string): Shape {}
}

In this case, ShapeManager is a high-level module while MySQL is a low-level module, but this is a violation of the Dependency Inversion Principle since we are forced to depend on MySQL.

If we want to change our database in the future we would have to edit the ShapeManager class and thus violates Open-Close Principle. In this case we should not care about which kind of database are we using, so to depend on abstractions on this case we will make use of an interface:

interface Database {
 connect(): Connection;
}

class MySQL implements Database {
 public connect(): Connetion {
 // creates a connection
 }
}

class ShapeManager {
 private database;

 constructor(database: Database) {
 this.database = database;
 }

 public load(name: string): Shape {}
}

And now our high-level and low-level modules are depending on abstractions.

Conclusion

When starting to write Object-Oriented programing the SOLID principles could be difficult to understand and, if they are understood, see where and when to apply them is not trivial. But they are an example of one of the most important things in software development, practice and experience will make you apply these principles in a very natural and intuitive way.

(This is an article posted to my blog at magarcia.io. You can read it online by clicking here.)

Adaptive Media Serving using Service Workers

Martin Garcia — Mon, 17 Jun 2019 00:00:00 +0000

Pairing with @Ester Martí

Everyone has experienced how visiting a web site over a slow network connection usually takes ages to load, making the experience very painful or completely impossible at all.

When it comes to web development, we usually tend to forget about load performance focusing more on adding new fancy features. But probably our users are not using the last brand new MacBook Pro connected to a 1Gps network. Is more likely that they are using a mid-range or low-end mobile device with a network connection that in the best case is a 3G connection.

In 2018, 52.2% of all global web pages were served to mobile phones.

So, taking care of performance is important and one of the most resource-consuming is media delivery. We are going to show how to adapt the media
delivery based on the network connection using the Network Information API. This is an improved version of an experiment I did with my coworker @Eduardo Aquiles as a React component, similar to what Max Böck explains in his article about connection-aware components but in this case, using service workers.

The Network Information API

The Network Information API is a draft specification that exposes an interface to JavaScript with information about the device connection.

The interface consists of a different set of attributes that gives us multiple information about the network. The most relevant for us in this article are:

type: The connection type that the user agent is using. (e.g. ‘wifi’, ‘cellular’, ‘ethernet’, etc.)
effectiveType The effective connection type that is determined using a combination of recently observed rtt and downlink values. (see table)
saveData Indicates when the user requested a reduced data usage.

effectiveType values

Table of effective connection types (ECT)

ECT	Minimum RTT (ms)	Maximum downlink (Kbps)	Explanation
slow‑2g	2000	50	The network is suited for small transfers only such as text-only pages.
2g	1400	70	The network is suited for transfers of small images.
3g	270	700	The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g	0	∞	The network is suited for HD video, real-time video, etc.

Browser support

The API does not have full browser support yet but is supported by the most popular mobile browsers
which are the ones where this technique will have more impact.

In fact, 70% of mobile users have this API enabled on their device.

Adaptive Media Serving

Our purpose will be to serve different media resources based on the information that we get from the effectiveType attribute. When we talk about different media resources it could be a completely different media, like switching between HD video, HD image or low quality image, the approach suggested by Addy Osmani.

In this example, we are going to use different compression levels for the same image.

First, we need to get the proper quality based on network conditions. This is easily reachable using the next snippet:

function getMediaQuality() {
  const connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;

  if (!connection) {
    return 'medium';
  }

  switch (connection.effectiveType) {
    case 'slow-2g':
    case '2g':
      return 'low';
    case '3g':
      return 'medium';
    case '4g':
      return 'high';
    default:
      return 'low';
  }
}

Imagine that we have an image server where we can specify the quality of the image that we want with a query parameter quality as low, medium or high. Therefore we can set the quality on the src attribute of the images tags as it follows:

<img src="http://images.magarcia.io/cute_cat?quality=low" alt="Cute cat" />

const images = document.querySelectorAll('img');
images.forEach(img => {
  img.src = img.src.replace('low', getMediaQuality());
});

It is important to notice that the default quality set on the image is low, which means that devices will load first the low quality image and then if it has a high-speed connection will load the better quality one.

Then the JavaScript snippet above will get all the images in the document and will replace the quality parameter to the appropriate one based on what the getMediaQuality function returns. If the quality is low is not going to do more requests, but if it changes it will do two requests: one with the low quality image when the browsers parse the img tag and another one with medium or high quality when the JavaScript code is executed.

This is not ideal but it will improve load times on slow networks. But for medium/high connection networks, as we mentioned before, it will make two requests for each image consuming more data than needed.

Using Service Workers

The problem mentioned regarding the two requests can be fixed using
service workers, intercepting the request made by the browser and replacing it with the appropriate quality for the image.

First, we need to register our service worker:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js').then(
      function(registration) {
        console.log('ServiceWorker registration successful with scope: ', registration.scope);
      },
      function(err) {
        console.log('ServiceWorker registration failed: ', err);
      }
    );
  });
}

Next, we add a listener for the fetch event, which for all the images requested from the site will append the right quality parameter using the getMediaQuality function created in the previous section.

self.addEventListener('fetch', function(event) {
  if (/\.jpg$|.png$|.webp$/.test(event.request.url)) {
    const url = event.request.url + `?quality=${getMediaQuality()}`;
    event.respondWith(fetch(url));
  }
});

And we don’t need to specify the quality parameter on the img tag anymore since the service worker will be in charge of that.

<img src=“http://images.magarcia.io/cute_cat” alt=“Cute cat”/>

The code

You can find the code of this post (a more complete, clean and with fewer bugs) on this GitHub repo.

BLoC Pattern with React Hooks

Martin Garcia — Mon, 18 Feb 2019 00:00:00 +0000

The BLoC Pattern has been designed by Paolo Soares and Cong Hui, from Google and first presented during the DartConf 2018 (January 23-24, 2018). See the video on YouTube.

BLoC stands for Business Logic Component. Initially was conceived to allow to reuse the same code between Flutter and Angular Dart, but in fact is independently of the platform: web application, mobile application, back-end.

It can be considered an alternative to the Redux port for flutter making use of Dart streams. In our case, we’re going to use Observables from the library RxJS, but any other option like xstream will be valid as well.

In short, the BLoC will:

contain business logic (ideally in bigger applications we will have multiple BLoCs)
rely exclusively on the use of Observables for both input (Observer) and output (Observable)
remain platform independent
remain environment independent

How BLoC works?

I’m not going to explain extensively how BLoC works (there is other people that did a better job I will do here), but just some basic hints.

The BLoC will hold the business logic and components will have no knowledge about what's happening inside. Components will send events_to the BLoC via _Observers and will be notified by the BLoC via Observables.

Implementing the BLoC

This is basic typescript example of a search BLoC using RxJS:

export class SearchBloc {
  private _results$: Observable<string[]>;
  private _preamble$: Observable<string>;
  private _query$ = new BehaviorSubject<string>('');

  constructor(private api: API) {
    this._results$ = this._query$.pipe(
      switchMap(query => {
        return observableFrom(this.api.search(query));
      })
    );
    this._preamble$ = this.results$.pipe(
      withLatestFrom(this._query$, (_, q) => {
        return q ? `Results for ${q}` : 'All results';
      })
    );
  }

  get results$(): Observable<string[]> {
    return this._results$;
  }

  get preamble$(): Observable<string> {
    return this._preamble$;
  }

  get query(): Observer<string> {
    return this._query$;
  }

  dispose() {
    this._query$.complete();
  }
}

results$ and preamble$ are exposed to be subscribed from a component and they express asynchronous values that change in response to changes in query.

query is exposed as Observer<string> to the outside, to allow the addition of new value from the components. Within SearchBloc , we have
_query$: BehaviorSubject<string> as the stream source, and the constructor declares _results$ and _preamble$ to respond to _query$.

Using it on React

In order to use it on React we need to create a new instance of the BLoC and share it to the child components using a React context.

const searchBloc = new SearchBloc(new API());
const SearchContext = React.createContext(searchBloc);

We have to expose it using the context provider:

const App = () => {
  const searchBloc = useContext(SearchContext);

  useEffect(() => {
    return searchBloc.dispose;
  }, [searchBloc]);

  return (
    <SearchContext.Provider>
      <SearchInput />
      <ResultList />
    </SearchContext.Provider>
  );
};

It’s important to have the useEffect returning the dispose method of the BLoC so it will complete the observer when the component is unmounted.

Then we can publish changes to the BLoC from the SearchInput component:

const SearchInput = () => {
   const searchBloc = useContext(SearchContext);
   const [query, setQuery] = useState("");

   useEffect(() => {
      searchBloc.query.next(query);
   }, [searchBloc, query]);

   return <input
            type="text"
            name="Search"
            value={query}
            onChange={({ target }) => setQuery(target.value)}
          />;
}

We got the BLoC using the hook useContext and then with useEffect every time the query change we publish the new value to the BLoC.

Now it’s time to the ResultList:

const ResultList = () => {
  const searchBloc = useContext(SearchContext);
  const [results, setResults] = useState([]);

  useEffect(() => {
    return searchBloc.results$.subscribe(setResults);
  }, [searchBloc]);

  return (
    <div>
      {results.map(({ id, name }) => (
        <div key={id}>{name}</div>
      ))}
    </div>
  );
};

As before, we use the useContext to get the BLoC, but now in the useEffect we subscribe the changes on the results$ interface to update the local state of the component. It’s important to return the return value of the subscribe, since it will unsubscribe when the component is unmounted.

Final thoughts

The final code is not complex, at least if you have a minimal knowledge about Observables and hooks. I have the feeling that the code is quite readable and helps to keep the business logic outside the components. It’s true that we should take care about to unsubscribe from the observables and dispose the BLoC when the components are unmounted, but these issues could be easily solvable creating some new hooks like useBlocObservable and useBlocObserver. But this I’ll try in the future, soon I hope, in a side project I’m using this pattern.

Originally published at magarcia.io on February 18, 2019.

Refactor TodoMVC with Redux Starter Kit

Martin Garcia — Sat, 26 Jan 2019 00:00:00 +0000

I've been working with React more than two years now. I started in a quite big project with a lot of work already done that was using Redux. I was a bit overwhelming start directly with so much stuff done, especially with a framework I didn't know much about. But after some time I got more comfortable and experienced.

Recently I discovered the project Redux Starter Kit from the same team that works on Redux. It's a simple toolset that provides utilities that can make really simple and easy work with Redux. In fact, one of the tools it provides, createReducer, is a patter I've been using for a while and it helps me a lot on reducing boilerplate code and speeding up my development (especially in new projects).

So in order to learn more about and get comfortable using it, I decided to migrate an already existing codebase with Redux, using this toolset. Obviously, as an example project for a frontend framework, I picked the omnipresent TodoMVC, in concrete the version that Redux provides as example in his repository.

Starting point

For whoever doesn't know how this app looks like in Redux, it has two main reducers visibilityFilter and todos; both with his respective actions, action creators and selectors.

Visibility Filter

I started with the most "simple" reducer, to start small and then move to a more complex state.

Reducer

The reducer, as it came from the Redux example, it's already quite simple and easy to understand.

// reducers/visibilityFilter.js
import { SET_VISIBILITY_FILTER } from '../constants/ActionTypes';
import { SHOW_ALL } from '../constants/TodoFilters';

export default (state = SHOW_ALL, action) => {
  switch (action.type) {
    case SET_VISIBILITY_FILTER:
      return action.filter;
    default:
      return state;
  }
};

In order to create reducers Redux Starter Kit provides a function createReducer, as I mentioned before it's a pattern I already used and I'm quite happy with it.

The idea is simple, instead of having to create a reducer function with a switch case statement inside, this function expects the initial state as a first parameter and an object where the keys are the action types and the value are the reducers ((state, action) => { /* reducer code */) for this action.

It reduces some boilerplate and will set always the default statement as return state. But to me, the biggest benefit is the readability that provides.

This is how the visibility filter reducer looks like using createReducer:

// reducers/visibilityFilter.js
import { createReducer } from 'redux-starter-kit';
import { SET_VISIBILITY_FILTER } from '../constants/ActionTypes';
import { SHOW_ALL } from '../constants/TodoFilters';

export default createReducer(SHOW_ALL, {
  [SET_VISIBILITY_FILTER]: (state, action) => action.filter
});

Actions creators

Now is time for the actions. The visibility filter only has one action SET_VISIBILITY_FILTER and the creator is very simple:

// actions/index.js
import * as types from '../constants/ActionTypes';

/* ... Other actions ...*/
export const setVisibilityFilter = filter => ({
  type: types.SET_VISIBILITY_FILTER,
  filter
});

For the actions, this toolset can be quite opinionated. It provides the function createAction that only expects the action type as a parameter. As a result, we get an action creator.

// actions/index.js
import * as types from '../constants/ActionTypes';

/* ... Other actions ...*/
export const setVisibilityFilter = createAction(types.SET_VISIBILITY_FILTER);

This action creator can be run with or without parameters. In the case that we send a parameter, this will be set as the payload of the action. These are some examples of how will work:

const setVisibilityFilter = createAction('SET_VISIBILITY_FILTER');

let action = setVisibilityFilter();
// { type: 'SET_VISIBILITY_FILTER' }

action = setVisibilityFilter('SHOW_COMPLETED');
// returns { type: 'SET_VISIBILITY_FILTER', payload: 'SHOW_COMPLETED' }

setVisibilityFilter.toString();
// 'SET_VISIBILITY_FILTER'

So now the filter is set into the payload key of the action, this implies a
refactor on the reducer since we were using the key filter, but luckily is
very simple to change.

// reducers/visibilityFilter.js
import { createReducer } from 'redux-starter-kit';
import { SET_VISIBILITY_FILTER } from '../constants/ActionTypes';
import { SHOW_ALL } from '../constants/TodoFilters';

export default createReducer(SHOW_ALL, {
  [SET_VISIBILITY_FILTER]: (state, action) => action.payload
});

Selectors

For me using selectors is one of the best choices that anyone can take when working with React, because it makes really simple refactor how the state looks like without having to change all the components that are consuming this part of the state.

The selector of the visibility filter is one of the easiest ones:

// selectors/index.js
const getVisibilityFilter = state => state.visibilityFilter;

/* ... Other selectors ...*/

And it doesn't change too much using the function createSelector. Actually, we have more code now than with the previous version, but trust me it's going to be simpler. Just keep reading.

// selectors/index.js
import { createSelector } from 'redux-starter-kit';

const getVisibilityFilter = createSelector(['visibilityFilter']);

/* ... Other selectors ...*/

Slices

Until now the only thing that we did is changing some simple functions to more simple functions using different creators. But now is where I discovered the real power of the toolset: createSlice.

createSlice is a function that accepts an initial state, an object full of reducer functions, and optionally a "slice name", and automatically generates action creators, action types, and selectors ready to be used.

Now we can throw all the code that we did.

Creating a slice for the visibility filter is very clean and easy to understand, and since we can throw all the previous code that we refactor the final result it's removing a lot of boilerplate.

// ducks/visibilityFilter.js
import { createSlice } from 'redux-starter-kit';

export default createSlice({
  slice: 'visibilityFilter',
  initialState: SHOW_ALL,
  reducers: {
    setVisibilityFilter: (state, action) => action.payload
  }
});

Now we have a single object as a result containing all that we need to work properly with Redux. This is how it can be used:

const reducer = combineReducers({
  visibilityFilter: visibilityFilter.reducer
});

const store = createStore(reducer);

store.dispatch(visibilityFilter.actions.setVisibilityFilter(SHOW_COMPLETED));
// -> { visibilityFilter: 'SHOW_COMPLETED' }

const state = store.getState();
console.log(visibilityFilter.selectors.getVisibilityFilter(state));
// -> SHOW_COMPLETED

All the changes did until now are in this commit.

Todos

The todos reducer is more complex so I'm not going to show the refactor step by step. Instead, I'm going to explain how the final result looks like, but if you are interested go directly the final result.

The first part is defining the initial state:

// ducks/todos.js
const initialState = [
  {
    text: 'Use Redux',
    completed: false,
    id: 0
  }
];

In order to make the slice creation more readable, I extracted the different reducer actions in different functions:

// ducks/todos.js
const addTodo = (state, action) => [
  ...state,
  {
    id: state.reduce((maxId, todo) => Math.max(todo.id, maxId), -1) + 1,
    completed: false,
    text: action.payload.text
  }
];

const deleteTodo = (state, action) => state.filter(todo => todo.id !== action.payload.id);

const editTodo = (state, action) =>
  state.map(todo =>
    todo.id === action.payload.id ? { ...todo, text: action.payload.text } : todo
  );

const completeTodo = (state, action) =>
  state.map(todo =>
    todo.id === action.payload.id ? { ...todo, completed: !todo.completed } : todo
  );
const completeAllTodos = state => {
  const areAllMarked = state.every(todo => todo.completed);
  return state.map(todo => ({
    ...todo,
    completed: !areAllMarked
  }));
};

const clearCompleted = state => state.filter(todo => todo.completed === false);

And now we can put all together in a new slice:

// ducks/todos.js
const todos = createSlice({
  slice: 'todos',
  initialState,
  reducers: {
    add: addTodo,
    delete: deleteTodo,
    edit: editTodo,
    complete: completeTodo,
    completeAll: completeAllTodos,
    clearCompleted: clearCompleted
  }
});

By default the selectors returned by createSlice are very simple, they just return the value from the state (eg: todos.selectors.getTodos). But in this application, we need to define more complex selectors.

For example, getVisibleTodos needs two know about the current visibility filter and also the todos. createSelector gets as a first parameter an array with strings (the path to select from the state) or other selectors and as a second parameter the function that's going to implement the logic that we want to select the todos based on the selected filter.

// ducks/todos.js
const { getVisibilityFilter } = visibilityFilter.selectors;

todos.selectors.getVisibleTodos = createSelector(
  [getVisibilityFilter, todos.selectors.getTodos],
  (visibilityFilter, todos) => {
    switch (visibilityFilter) {
      case SHOW_ALL:
        return todos;
      case SHOW_COMPLETED:
        return todos.filter(t => t.completed);
      case SHOW_ACTIVE:
        return todos.filter(t => !t.completed);
      default:
        throw new Error('Unknown filter: ' + visibilityFilter);
    }
  }
);

todos.selectors.getCompletedTodoCount = createSelector(
  [todos.selectors.getTodos],
  todos => todos.reduce((count, todo) => (todo.completed ? count + 1 : count), 0)
);

As you can notice in the previous code, I created the new selectors in the selectors object in the todos slice so now we have all the selectors accessible in the same place.

Create Store

The last two functions provided by the library are configureStore and
getDefaultMiddleware.

configureStore is an abstraction over the standard Redux createStore
function. Doesn't provide more functionalities than createStore but it makes things easier to read, like enable developer tools that is just a boolean.

getDefaultMiddleware returns a list of middlewares
[immutableStateInvariant, thunk, serializableStateInvariant] in development
and [thunk] in production.

redux-immutable-state-invariant: It can detect mutations in reducers during a dispatch, and also mutations that occur between dispatches (eg: in selectors or components).
serializable-state-invariant-middleware: It deeply checks your state tree and your actions for non-serializable values such as functions, Promises, etc.

// store.js
import { configureStore, getDefaultMiddleware } from 'redux-starter-kit';
import { combineReducers } from 'redux';
import { visibilityFilter, todos } from './ducks';

const preloadedState = {
  todos: [
    {
      text: 'Use Redux',
      completed: false,
      id: 0
    }
  ]
};

const reducer = combineReducers({
  todos: todos.reducer,
  visibilityFilter: visibilityFilter.reducer
});

const middleware = [...getDefaultMiddleware()];

export const store = configureStore({
  reducer,
  middleware,
  devTools: process.env.NODE_ENV !== 'production',
  preloadedState
});

Final thoughts

Redux Starter Kit looks interesting, it reduces boilerplate code making the code cleaner and easy to understand. But also it makes really fast to develop new code.

Source Code: https://github.com/magarcia/todomvc-redux-starter-kit

Originally published at magarcia.io on January 26, 2019..

Forem: Martin Garcia

Check for undefined in JavaScript

The intuitive way

The “safe” way

Reading the type

Using void

Which way is better

The power of MVP

SOLID — Principles of Object-Oriented Design

SOLID Principles are a valuable tool to write good object-oriented software. This article tries to put some light on the subject with simple explanations and examples for each principle using TypeScript.

SRP — Single Responsibility Principle

OCP — Open-Closed Principle

LSP — Liskov Substitution Principle

ISP — Interface Segregation Principle

DIP — Dependency Inversion Principle

Conclusion

Adaptive Media Serving using Service Workers

The Network Information API

effectiveType values

Browser support

Adaptive Media Serving

Using Service Workers

The code

Further Reading

BLoC Pattern with React Hooks

How BLoC works?

Implementing the BLoC

Using it on React

Final thoughts

Refactor TodoMVC with Redux Starter Kit

Starting point

Visibility Filter

Reducer

Actions creators

Selectors

Slices

Todos

Create Store

Final thoughts

Using `void`