DEV Community: Akshay Nair

JS Magic Tricks to impress your friends

Akshay Nair — Fri, 29 Mar 2019 18:30:00 +0000

My name is Houdini J.S. Magnifico. What I’m about to perform here are a set of illusions and magic tricks that are sure to blow your mind! So prepare to be amazed!

The tricks shown here are performed by trained professionals. Do not attempt these stunts at home. Do it at your office.Viewer discretion is advised.

Let’s-a go!

For my first trick, I’m gonna make this function… DISAPPEAR!

This is my totally normal, nothing weird about it, stop asking me, function.

Let me just wave Brendan Eich’s mouse pad over it for a bit… and… BOOM!

GONE! The function is not a function anymore. Schrodinger’s function has dissappeared!

audience applauds

Thank you! Thank you!

Here’s how it works

const innocentTotallyNormalFunction = (() => {}).apply.bind();
// Works with any method's bind();

Weird right? It’s called JavaScript and a lot of people use this in production. The reason this doesn’t work is because .apply method expects the context of a function but .bind gives it undefined as the context. this.means that the apply method doesn’t know which function it is trying to apply. Then the apply method has an identity crisis and everything goes to shit.

Magic list

Here I have a function that clones an array. Perfectly normal, production ready code.

const clone = list => list.reduce((newList, item) => [...newList, item], []);

// Another clone implementation you can use is,
const clone = Object.values;

// Or if you wanna go old school...
const clone = list => {
  const newList = [];

  for(let index in list) {
    newList.push(list[index]);
  }

  return newList;
};

Here’s an ordinary list with nothing fishy going on inside

I’m just gonna casually use the clone function to copy the list and check the length of the newly created list…

Magic!!

The list is no longer 23 items long. 23 to 1! Next-gen compression algorithm, question mark? Or is it just magic?

Well, here's how it all went down

The concept behind this is one that not many developers are familiar with. Array holes, also called empty slots are points in an array that are empty. No, I’m not talking about undefined or null or 0. Just empty.

Ref: Array holes/empty slots, Sparse arrays

Array(5) // >> [<empty x 5>]

// In ES2015, you can also do
[,,,,,] // >> [<empty x 5>]

This creates an array of 5 items but without any values. But javascript doesn’t use undefined as the default values tho. It instead creates empty slots (holes) in the arrays but keeps given the length. So when you copy it using the reduce method, it doesn’t iterate over the empty slots. So the newly generated array is shorter.

Schrodinger’s magic list

The list we are gonna be working on is document.all which is a list of all nodes in a document.

Council of W3C, give me the strength to make this list disappear!!! Boom! Shaa! Waka-Waka Boom!

Be Amazed!!

Go get an MRI scan because your tiny little brain just exploded!

Here’s the big reveal!

document.all is a very old and deprecated api that allowed you to iterate over all the nodes rendered to the DOM. The typeof expression returning undefined was by design as a part of deprecation of that non-standard feature. Weird, I know. But that’s just how javascript rolls.

Are we Infinity yet?

Let’s take a number, let x: number.

x + 1 === x; // >> true
x + 2 === x; // >> false

“What just happened?”

I added 1 to x and the value didn’t change! Then I added 2 to it and… the universe… it changed.

Check out how this works

const x = 1e16; // OR 1 * Math.pow(10, 16) OR 10000000000000000

This is by design. It’s documented in IEEE 754-2008. When the number is as large as this, it rounds it up to the nearest even number.

Ref: Rounding rules section in IEEE 754

Is a “not a number” a number or not a number? Well, it’s NaN of your business

typeof NaN === 'number' // >> true
NaN !== NaN // >> true

Wut? ‘Not a number’ is a number and ‘Not a number’ is not equal to ‘Not a number’

Javascript is a magical language

Know the trick

NaN is a numeric data type but it behaves as an identity when any mathematical operation is applied to it.

“But why is NaN === NaN returning false?”

Because the Gods of Javascript wished so. If either side of === operator is NaN, the operation returns false. Thats just how it works. Don’t question it.

Check if your list has more than 1 items

A very complicated problem in programming.

A normie dev would go ahead and write something like

const hasAtleast2Elements = x => x.length >= 2;

That solution is 13 characters long. In the modern world of javascript, 13 characters is way too many characters. It is a performance bottleneck.

Let’s write something more optimized in size

const hasAtleast2Elements = x => !isNaN(+x);

There. 10 characters. Much better. We removed 23% of our JavaScript! Good job. Less JavaScript is good JavaScript

The genius behind this action

We improved our load time by 23% but at what cost?! How does that function even work? Magic?

The + operator applied to a list returns NaN if the number of items in the list is more than 1.

Why does it do that? Well, type casting. +[] is equal to +[].toString().

So,

[].toString() === '' // >> +'' === 0
[1].toString() === '1' // >> +'1' === 1
[1, 2].toString() === '1,2' // >> +'1,2' === NaN (Cannot typecast as it is not a number)

That’s all for today! Tune in next time to watch Magnifico use magic in production and get fired immediately.

Now I’m gonna make myself disappear.

…

Why is this… Just a second folks… Some technical difficul…

Poof

Grandma's recipes for cooking redux

Akshay Nair — Fri, 15 Mar 2019 18:30:00 +0000

Welcome to my Grandma’s Kitchen. I’m your host, the grandson. Let’s start cooking, shall we?

Disclaimer: Stuff referenced in this post are not my opinions, they are straight up facts. If you disagree, go ahead and give this post 50 slaps (It’s the same button as the clap one. Just click on it more aggressively and it gets marked as a slap). Reader discretion is advised.

For far too long have we suffered the torture of writing boilerplate code and messy actions. Not anymore. Here are some recipes to cook redux the way my grandma wants you to.

We are going to be cooking with the following ingredients today -

Redux Saga
Redux Utils
Crocks
Reselect
Ramda (optional. Add according to taste)

Spicy hot action names/types

You wouldn’t expect there to be any changes in the way you create action names/types but why not? Go check your action types file. You will find that there is a recurring pattern of the three states. ACTION_PENDING, ACTION_SUCCESS and ACTION_FAILURE (not FAIL because PENDING, SUCCESS and FAILURE have the same number of characters and my grandma likes consistency). And while we are at it we can also learn something from the REST architecture from my grandma’s time and bring the resource/action pattern in here.

actionTypes function uses the @resource/ACTION/STATE convention.

import { actionTypes } from '@phenax/redux-utils';

const types = actionTypes({
  DISHES: {
    LIST: ['PENDING', 'SUCCESS', 'FAILURE'],
    ADD: ['PENDING', 'SUCCESS', 'FAILURE'],
  },
  SESSION: {
    INIT: ['PENDING', 'SUCCESS', 'FAILURE'],
  },
});

types.DISHES.ADD.SUCCESS === '@dishes/ADD/SUCCESS'; // true

// Your actions will then look something like
dispatch({
  type: types.DISHES.ADD._,
  payload: {
    name: 'Chicken that tastes like paneer’,
    ingredients: {
      chicken: { count: 1, unit: 'bird' },
      salt: { toTaste: true },
      pepper: { count: 2, unit: 'shakes' },
      milk: { count: 3, unit: 'seconds of pouring' },
    },
  },
});

// The underescore (`._`) is the dispatch that gets picked up by the sagas. Its a default dispatch i.e. stateless dispatch.

Reducer salad

The three state pattern is also seen repeated a lot inside reducers. My grandma keeps telling me “My back hurts when I scroll through long switch-case statements”. So if you haven’t guessed already, we are going to change that too now. We have to care for the elderly.

import { createPartialReducer, mergeReducers } from '@phenax/redux-utils';

const initialState = { loading: false, readyForServing: true, dishes: [], error: '' };

const getLoadingState = state => ({ readyForServing }) => ({
  ...state,
  readyForServing,
  loading: true,
});

const addDishReducer = createPartialReducer(types.DISHES.ADD, (state = initialState, action) => ({
  PENDING: getLoadingState(state),
  SUCCESS: newDish => ({
    ...state,
    readyForServing: true,
    loading: true,
    dishes: [...state.dishes, newDish],
  }),
  FAILURE: e => ({
    ...state,
    readyForServing: false,
    loading: true,
    error: e.message,
  }),
}));

// Your regular reducer can be merged with partials
const regularOldReducer = (state = initialState, action) => {
  switch(action.type) {
    case types.SOMEOTHER.ACTION.PENDING:
      return {
        ...state,
        loading: true,
      };
    case types.SOMEOTHER.ACTION.SUCCESS:
      return {
        ...state,
        loading: false,
        dishes: [],
      };
    case types.SOMEOTHER.ACTION.FAILURE:
      return {
        ...state,
        loading: false,
        dishes: [],
        error: e.message,
      };
  }
};

export default mergeReducers(addDishReducer, regularOldReducer);

The partial reducers allow you to split the reducer into smaller functions based on the resource/action/state convention. You can also use this to show off your rad point-free trick shots.

Duck promises

There are 3 different ways to interpret name of this dish. Clue, it’s not a typo (even though it fits perfectly). Another clue, we’re not cooking a duck here. You are correct. Just duck those promises and go with Async from crocks. (Not to be confused with async/await which is just a prank that the C# community is playing on us disguised as w3c draft authors). Here's how to use fetch (or any other promise based api) and turn it into a composible, cancellable, lazy Async task. Grandma does not approve laziness but we will use it anyway because GOD DAMMIT, IT'S MY FREAKING COOKING SHOW! GET OUT OF MY ROOM, GRANDMA!

For you, a simple made-up example of fetching with network timeout. fetchJson is just an Async wrapper for fetch api.

import Async from 'crocks/Async';
import { prop, filter, map, either, complement } from 'ramda';
import { fetchJson } from '@phenax/redux-utils/async';

// Some other api call that happens after we get the data from the user
// fetchChefInfo :: a -> Async a
const fetchChefInfo = data => Async((rej, res) => setTimeout(() => res(data), 700));

// fetchServableDishes :: Object * -> Async [User]
const fetchServableDishes = params => fetchJson('/dishes', params)
  .race(Async.rejectAfter(2000, new Error('Request Timeout')))
  .map(prop('dishes'))
  .map(compose(
    filter,
    complement,
    either(
      prop('isReady'),
      prop('isBurnt'),
    ),
  ));

let task = fetchServableDishes();

// The request has not been sent yet (it's lazy like crazy! Thank you. Thank you.). You can keep composing and chaining stuff
task = task
  .map(map(decorateDish))
  .chain(fetchChefInfo);

// And when you finally decide that you want to make the api call, you can fork it.
// Nothing is executed till you call .fork
task.fork(
  e => console.error(e),
  activeUsers => {
    // Do stuff
  },
);

Barbecue sagas

Redux saga is the best way to write actions. That is a fact, not an opinion. No need to look it up. Not going to change anything with that but we can add a few ingredients to enhance its flavor. We are also going to use Async instead of Promise because my grandma believes you shouldn't make promises you can't keep/manage.

import { put } from 'redux-saga/effects';
import { callAsync, putResponse } from '@phenax/redux-utils/saga';

export function* add({ payload }) {
  yield put({ type: types.DISHES.ADD.PENDING, payload: {} });
  const response = yield callAsync(saveNewDish, payload);
  yield putResponse(types.DISHES.ADD, response);
};

export function* list({ payload }) {
  yield put({ type: types.DISHES.LIST.PENDING, payload: {} });
  const response = yield callAsync(fetchServableDishes);
  yield putResponse(types.DISHES.LIST, response);
};

export default function* root() {
  yield all([takeLatest(types.DISHES.ADD._, add)]);
  yield all([takeLatest(types.DISHES.LIST._, list)]);
};

Here,

yield putResponse(types.DISHES.LIST, response);
// is just a shorthand for
yield put(response.cata({
  Success: data => ({ type: types.DISHES.LIST.SUCCESS, payload: data }),
  Failure: error => ({ type: types.DISHES.LIST.FAILURE, payload: error }),
}));

Selector noodles

Selectors allow you to derive your data from the state and memoize the operation. We are going to use reselect for this and we’re also gonna sprinkle some ramda in there according to taste. You can use lodash too but why would you do something like that? Ramda is to lodash what a smart watch is to a tin-can telephone.

Grandma: “Back in my day, underscore was pretty popular. It was like…”.

Yeah grandma, we get it, you’re old. Now shut up and let me show these people some selector action.

import { createSelector } from "reselect";
import { pathOr, prop, __, map } from 'ramda';

// selectBurntDishes :: { dishes :: { dishIds :: [String], items :: Object Profile } } -> [String]
export const selectBurntDishes = createSelector(
  pathOr({}, ['dishes', 'items']),
  pathOr([], ['dishes', 'dishIds']),
  (items, dishIds) => dishIds.filter(compose(
    prop('isBurnt'),
    map(prop(__, items)),
  )),
);

Now you can use it anywhere…

In you component’s mapStateToProps,

const mapStateToProps = state => ({
  burntDishes: selectBurntDishes(state),
});

export default connect(mapStateToProps)(ListBurntDishes);

In your sagas,

function* mySaga() {
  const burntDishes = yield select(selectBurntDishes);
  // Do stuff with those ids
}

Doesn’t that look pretty? If you’re new to the point-free way, you may feel like you just watched a french movie without subtitles but trust me, this is worth the confusing first few days.

Conclusion

Old ideas and opinions are what new ones are born from. Grandma’s recipes were great and they’ve come out of experience that doesn’t mean we have to keep making the same thing a billion times. Small (and sometimes large) migrations are a good thing.

So let’s summarise. What did we learn today?

Use grandma’s favorite convention of @resource/ACTION/STATE for your action types
The elderly hate long switch case statements
Duck promises because Async rocks!
Sagas are the freakin best!!
Memoize those selectors for a better tomorrow

These are all solutions to the small yet annoying inconveniences that I ran into while working on a personal project of mine. I’m collecting all of the tiny helpers over at @phenax/redux-utils. The project is not done yet so the library will be getting more updates. PRs are welcome!!

Hope these ideas help you write some tasty code.

PureFunctionalJS - Sum Types In JavaScript

Akshay Nair — Thu, 14 Mar 2019 18:30:00 +0000

JavaScript has a very bad reputation in most developer communities. So much so that, “Writing cleaner and safer JavaScript…” in the title may already seem a bit redundant to most readers. A lot of that has to do with loose typing, invalid values and the horrible chain of ternary expressions or heaven forbid, if statements to handle them. With JavaScript, all functions run on the concept of “pretend what you are getting is what you asked for”. If the value is not valid for the kind of operation you are running on it, well, too bad. To save yourself from this, you can write run-time validations, add type-checks, etc but the core of the problem is till left largely unsolved.

Let’s learn from Haskell

Functional programming languages like Haskell have a clear solution for this. Sum Types! Sum Type (or Tagged Union) is an Algebraic Data Type which describes values that can take on several different types. Popular examples in haskell are the Maybe monad (for handling the validity of values) and the Either monad (for error handling).

Don’t worry. Maybe, I don’t know anything about monads Either (see what I did there?). All we need to know is that a Sum Type is a has multiple named constructors.

In Haskell, a Sum type looks something like this -

data MetalGenre = ProgMetal | DeathCore

scream :: MetalGenre -> IO ()
scream genre = putStrLn $ case genre of
  ProgMetal -> "Oh!"
  DeathCore -> "BleaAaAHHH!!"

main :: IO()
main = scream ProgMetal

Here, MetalGenre is the type and ProgMetal, DeathCore are constructors of that type.

A really popular and useful example of a Sum type in the functional world is the Maybe type. In Haskell, Maybe is a monad that wraps a value and helps you make sure that invalid values are not acted upon, thus allowing you to write safer functions.

This is what Maybe’s definition looks like in Haskell -

data Maybe = Just a | Nothing

Now here, all valid values will be wrapped in a Just and all invalid values will be wrapped in a Nothing. This way, we can handle invalid values in a clean and elegant way and be sure of the fact that the function is only called for the valid values.

You might be thinking, “But isn’t this only possible because Haskell is a statically typed beauty and JavaScript is the spawn of satan?”. Maybe it isn’t. (The joke’s getting old now)

EnumFP

Shameless self-plug alert!

I have a library to help with that! (Said every JavaScript developer ever).

EnumFP (PRs welcome)

EnumFP is a simple and light-weight way to create Sum types in JavaScript. Inspired by the awesomeness of Haskell, the library is written with safety in mind.

This is what the metal genre example would look like with EnumFP.

const MetalGenre = Enum(['ProgMetal', 'DeathCore'])

const scream = compose(console.log, MetalGenre.cata({
  ProgMetal: () => "Oh!",
  DeathCore: () => "BleaAaAHHH!!",
}));

scream(MetalGenre.ProgMetal());

Maybe, maybe?

The concept of what a Maybe does is more important than the implementation itself. Containing a value in a way that allows you to perform a set of operations on the container and not worry about the validity of the input is what Maybe is about.

You can implement a simple Maybe and a couple of utility functions using EnumFP. EnumFP also allows you to add argument descriptions. This example uses the caseOf function which is like match but for partial application).

const Maybe = Enum({ Just: ['value'], Nothing: [] });

// fmap :: (a -> b) -> Maybe a -> Maybe b
const fmap = fn => Maybe.cata({
  Just: compose(Maybe.Just, fn),
  Nothing: Maybe.Nothing,
});

// mjoin :: Maybe Maybe a -> Maybe a
const mjoin = Maybe.cata({
  Just: x => x,
  Nothing: Maybe.Nothing,
});

// chain :: (a -> Maybe b) -> Maybe a -> Maybe b
const chain = fn => compose(mjoin, fmap(fn));

Here,

fmap returns a new Maybe and runs the function over the value inside, in case of Just and ignores a Nothing. (Like Array.prototype.map)

mjoin unwraps a given nested Maybe. Because many monads like Maybe, are agnostic about the value inside, you can put the monad inside another monad (That’s what shesaid) (Like Array.prototype.flatten)

chain maps over the Maybe and then flattens the resulting nested Maybe. (Like Array.prototype.flatMap).

Let’s use this and write a function that accepts a User instance and gives you the first name without throwing an error for invalid user or invalid name.

// head :: [a] -> Maybe a
const head = arr => (arr.length ? Maybe.Just(arr[0]) : Maybe.Nothing());

// prop :: String -> Object a -> Maybe a
const prop = key => obj => key in obj ? Maybe.Just(obj[key]) : Maybe.Nothing();

// trim :: String -> String
const trim = str => str.trim();

// split :: String -> String -> [String]
const split = seperator => str => str.split(seperator);

// safeUser :: User -> Maybe User
const safeUser = user => isUserValid(user) ? Maybe.Just(user) : Maybe.Nothing();

// getFirstName :: User -> Maybe String
const getFirstName = compose(
    chain(head), // Maybe [String] -> Maybe String
    fmap(split(' ')), // Maybe String -> Maybe [String]
    fmap(trim), // Maybe String -> Maybe String
    chain(prop('name')), // Maybe User -> Maybe String
    safeUser, // User -> Maybe User
);

Maybe.match(getFirstName(user), {
    Just: name => console.log('My name is', name),
    Nothing: () => console.log('Whats in a name?'),
});

In the example above, we first convert the user to a safe user by wrapping it in a Maybe. Then we get the user’s name using the prop function. The prop and head functions here, instead of returning the value, wraps the value in a Maybe. This is why to map it and then unwrap it, we use chain instead of fmap.

Working with React

Yes, EnumFP works well with react! (Jumping from one over-populated community to the next).

With the new react hooks being introduced in 16.8, it would be a sin not to mention it here. EnumFP ships with a useReducer hook which is a simple wrapper around react’s useReducer.

Don’t want to upgrade to 16.8? Do you still watch reruns of Seinfeld? Want to wait for your grand-children to help you with the upgrade… and… walking?

No worries. There’s an HOC available as well.

You can find out more about integrations with react here.

And this is not limited to just component state tho. You can use Sum Types to work with any kind of enumerable state values. From handling Success, Pending and Failure states for any action to containing values based on it’s type or validity. Sum Types are here to clean up all of that.

Conclusion

This is just the tip of the iceberg. There are a lot more of these amazing ideas hidden in the world of functional programming, waiting to move to other languages. Being a part of the JavaScript community for a while has made me realise that it’s not all bad. What we lack in language features and standard library, we make up for in the variety of libraries just an npm install away, and the strong community constantly working towards “Making JS great again”. So let’s build a wall together between us and bad code. Covfefe.