DEV Community: Richard Torruellas

Do you know what a virtual list is?

Richard Torruellas — Wed, 13 May 2020 21:09:35 +0000

One of first learning segments I am working on is about virtual lists, what they are, why we use them, and how to create your own from scratch!

Before we can get to building something, or choosing a solution (like a virtual list), we should first have a problem where we need the thing we are building.

Lots of optimizations come with a cost. Optimizations aren't always more performant, even though the name "optimization" gives the illusion that it is. The other cost is the abstraction or sometimes confusing code you'll have to maintain this new optimization.

When building applications, its only a matter of time before you are asked to render large data sets to the screen. To use a concept we all know, imagine you had to create Twitter. Twitter has an endless amount of tweets you can scroll through. Now imagine what that can do to the performance of the browser or your non browser application. To scroll through tweets, you need to put these tweets in render all of these tweets to the screen. Eventually you will hit a problem where your first render will be expensive since you would have to render thousands of tweets.

The "simple" solution, introduced to the web in the early 2000s, would be to only render what could fit on the page, and ajax more once you hit the bottom of the page. This is a technique that combines a backend that can paginate requests, and client code that knows when to request more data and render it.

Virtual lists can work in this way as well, but it is a bit smarter. Not only will a virtual list only render what could be visible, but it will remove items from the screen as you scroll away from them, where the user would never see them anyway. This helps with memory, animations, and overall better user experience when done correctly.

Want to build one from scratch so you can understand this concept fully? Subscribe to our newsletter and be one of the first readers to learn how to build one!

weekend.dev Episode 1

Richard Torruellas — Sun, 19 Apr 2020 22:58:34 +0000

Hey folks, listen to my first ever podcast. Would love feedback!

I discuss stuff that happened this week in the JavaScript world.

https://anchor.fm/weekenddev/episodes/Episode-1---crankjs--romejs--types-vs-tests-ed0cqk/a-a1vq8eq

RE: How can open source contributors and maintainers engage in a respectful ongoing relationship?

Richard Torruellas — Sat, 22 Feb 2020 15:26:57 +0000

Don’t be an asshole

Typescript without Typescript

Richard Torruellas — Tue, 14 Jan 2020 16:04:06 +0000

Typescript is fantastic. It will never be as sound as something like elm or Haskell, but it is what it is, and you should probably use it. The benefits of typescript itself can be read across the internet. This post isn’t the first or last to talk about typescript. What this post aims to achieve is showing how you can use typescript without having to fully commit to writing typescript yourself.

Although there are great projects like parcel and tsdx, setting up new (or even worse) or already-in-production apps to use typescript is not exactly easy. It takes time. Lots of confusing time.

Setup

cd your-project #(or make new project)
npm init
npm install typescript --save-dev
npx tsc --init

Check out the options in the tsconfig.json file to get an understanding of the options.

After looking over tsconfig.json, make it look like this

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "strict": true
  }
}

Create index.js

touch index.js

Add some code to index.js

function sumTwo(a, b) {
  return a + b
}

Now, if you're already using vscode, you will see where this is headed.

Run

npx tsc --noEmit

and you should see something like

λ npx tsc --noEmit
src/index.js:1:17 - error TS7006: Parameter 'a' implicitly has an 'any' type.

1 function sumTwo(a, b) {
                  ~

src/index.js:1:20 - error TS7006: Parameter 'b' implicitly has an 'any' type.

1 function sumTwo(a, b) {

Closing

As you can see, without even having to fully invest in Typescript, you can still use it's compiler to help typecheck your code.

In future posts I want to also show:

How you can interop with libraries
How you can add types to your javascript files
Awesome integration with vscode

Towards a safer JavaScript

Richard Torruellas — Sun, 12 Jan 2020 21:01:42 +0000

As programs become large, their complexity also grows. Bugs become harder to track down, mistakes easier to make.

What if we could make small parts of our application more predictable? What if we could start to create fewer places where bugs originate?

By adopting few basic principals, we can start having more predictable outcomes.

Everything must return a value
A function called with the same arguments will return the same value

These constraints were popularized by something called Functional Programming.

Another property of Functional Programming is that everything is a function (surprise). Let's understand what these three constraints give us.

(these examples are for understanding, not to copy and paste into your application)

Everything must return a value?

// application.js
import { setPersonsName } from "./person";

console.log(setPersonsName({ name: undefined, age: undefined }, "bob"));
//> undefined

Above, someone is breaking our rules. setPersonsName returns no value. In a small and simple program, this might be "predictable" because you can easily look up what setPersonsName from ./person does (maybe). Imagine this application grows over the years, and to understand what setPersonsName does, we would have to potentially step through many lines of indirection and irrelevant code. Maybe not, maybe your application is an outlier and perfect. By not returning a value, we don't really know what setPersonsName or is used for. It could be setting values somewhere or it could do nothing.

Instead, we could choose a constraint that everything must return a value. Maybe it can set the name property on a person object?

// application.js
import { setPersonsName } from "./person";

console.log(setPersonsName("bob"));
//> {name: "bob", age: undefined}

Already we can see some benefit. We could write some tests that test the value of setPersonsName!

A function called with the same arguments will return the same value

import { setPersonsName } from "./person";

console.log(setPersonsName("bob"));
//> {name: "bob", age: undefined}

console.log(setPersonsName("bob"));
//> {name: "bob", age: 42}

Above, we can see setPersonsName now breaks our second rule of "A function called with the same arguments will return the same value". Hey, at least we have something being returned, right? But why are we now seeing the age property set to 42? We didn't change it! Who did? Who knows?

This is a common place of bugs in much of the software that I've maintained over the years. Not understanding where and how things changed over time. Let's not do that if we can.

Everything must return a value + A function called with the same arguments will return the same value

So how might we go about writing a better API for our teammates? What if instead of modifying some data outside of our control, we could provide setPersonsName with a copy of the data that needs to be modified? We could then a copy of the value we provided.

setPersonsName({ name: undefined, age: undefined }, "bob");
//> {name: "bob", age: undefined}
setPersonsName({ name: undefined, age: undefined }, "bob");
//> {name: "bob", age: undefined}

That might look something like

function setPersonsName(person, name) {
  return { ...person, name };
}

Everything is a function

If we apply the two above constraints with a third, everything must be a function, we are getting close to Functional Programming. The rest of what you learn about Functional Programming are abstractions to make these constraints easier to deal with, while maintaining these constraints.

everything must be a function
everything has a value
everything must return the same value given the same arguments

Abstractions

Sharing data over time with partial applications

Maybe at the start of a program you want to set some state, then later add to that state for a new value. One way we can do this is with partial applications.

function personData(person, fn) {
  let _person = { name: undefined, age: undefined, ...person };
  return fn(_person);
}

const a = personData(
  {
    name: undefined,
    age: undefined
  },
  person => ({ ...person, age: 23 })
);
// a = {name: undefined, age: 23}

const person = personData(a, person => ({ ...person, name: "bob" }));
// person = {name: "bob", age: 23}

This might be a little too much work, so like anything, we can abstract even further. Using a new abstraction, sometimes called "pipe" can help us here. It takes a list of functions and applies the previous functions result and calls it with that.

const pipe = (...fns) => x => fns.reduce((y, f) => f(y), x);

const person = pipe(
  person => ({ ...person, age: 23 }),
  person => ({ ...person, name: "bob" })
);

// person() = {name: "bob", age: 23}

Pipe expanded for readability.

function pipe(...listOfFunctions) {
  return function(dataTheFunctionsOperateOn) {
    return listOfFunctions.reduce(
      (data, functionFromList) => functionFromList(data),
      dataTheFunctionsOperateOn
    );
  };
}

If we reintroduce the concept of partial applications, we can even come up with something a little nicer to look at.

const pipe = (...fns) => x => fns.reduce((y, f) => f(y), x);
const partiallyApply = (f, a) => b => f(a, b);

const setNameOnObject = (name, x) => ({ ...x, name });
const setAgeOnObject = (age, x) => ({ ...x, age });

const person = pipe(
  partiallyApply(setNameOnObject, "bob"),
  partiallyApply(setAgeOnObject, 24)
);
// person() = {name: "bob", age: 23}

In the future, there will be a Pipe Operator built into the language, which will make this type of programming even nicer. Link to MDN about the proposed Pipe Operator.

const partiallyApply = (f, a) => b => f(a, b);

const setNameOnObject = (name, x) => ({ ...x, name });
const setAgeOnObject = (age, x) => ({ ...x, age });

const person =
  partiallyApply(setNameOnObject, "bob") |> partiallyApply(setAgeOnObject, 24);

// person = {name: "bob", age: 23}

A New Data Type

So maybe we want more ways to set some data in a safer way that we can operate on. Some values in JavaScript we can map on. For example, Arrays have a map method. The map method allows us to call a function on each value, then returns a new array leaving the previous array unmodified (mutated). What if we could have more values in JavaScript that had map methods?

const Value = value => ({
  value,
  map: apply => Value(apply(value)),
  flatMap: apply => apply(value)
});

const person = Value({ name: undefined, age: undefined });

const newPerson = person.map(o => setNameOnObject("bob", o));
const newPersonTwo = newPerson.map(o => setAgeOnObject(24, o));

console.log(person.value, newPersonTwo.value);
// person.value = Object { name: undefined, age: undefined }
// newPersonTwo.value = Object { name: "bob", age: 24 }

But what if we take some of the patterns and abstractions we learned above to this new Value type? We can start to compose even more.

const person = Value({ name: undefined, age: undefined }).map(
  pipe(
    partiallyApply(setNameOnObject, "bob"),
    partiallyApply(setAgeOnObject, 24)
  )
);

When we start to get familiar with new data types, we can refined their usage even more. Maybe you have a different mental model and want to set things a little differently.

const flatten = fns => [].concat.apply([], fns);
const pipe = (...fns) => x => flatten(fns).reduce((y, f) => f(y), x);
const Value = value => ({
  value,
  map: apply => Value(apply(value)),
  flatMap: apply => apply(value)
});

const person = Value({ name: undefined, age: undefined });
const setName = name => p => p.map(o => ({ ...o, name }));
const setAge = age => p => p.map(o => ({ ...o, age }));
const setPropertiesOn = obj => (...fns) => {
  return pipe(fns)(obj);
};

const a = pipe(setName("pam"), setAge(55))(person);
const b = setPropertiesOn(person)(setName("pam"), setAge(55));
// a.value = Object { name: "pam", age: 55 }
// b.value = Object { name: "pam", age: 55 }

Maybe you just want to call a function on your new value. Do something "interesting" with it, without needing to create a new Value.

You can do this with flatMap.

const flatten = fns => [].concat.apply([], fns);
const pipe = (...fns) => x => flatten(fns).reduce((y, f) => f(y), x);

const Value = value => ({
  value,
  map: apply => Value(apply(value)),
  flatMap: apply => apply(value)
});

const toJson = obj => JSON.stringify(obj);

const post = async body =>
  fetch("https://httpbin.org/post", {
    method: "POST",
    headers: {
      Accept: "application/json",
      "Content-Type": "application/json"
    },
    body
  });

const getJsonFromResponse = async response => {
  const r = await response;
  const json = await r.json();
  return json;
};

async function createUser(name, age) {
  return await Value({ name, age }).flatMap(
    pipe(toJson, post, getJsonFromResponse)
  );
}

async function handleUserSubmit() {
  const user = await createUser("pam", 56);
  console.log(JSON.parse(user.data));
  // Object { name: "pam", age: 56 }
}

The future

I hope that in the future we have more of these utilities built into the language. Imagine if we had first class support for this new data type and Pipe. We could safely call functions on those values using pipe and a whole no ecosystem of nice utility functions would be published by the Javascript community.

We do have languages that can compile to JavaScript that have some of these nice features built in. For example, ReasonML has syntax for pipe.

Closing

We made a few safe and predictable programs by always returning a value, but never modifying any previous values. We always copy a value and return a new one. We will never have to worry about why something changed over time without us knowing.

We actually overlooked a lot of reasons that make functional programming great. Things like Immutability and Memorization for safety and performance, or things like concurrency. I hope by mentioning them, you will take it upon yourself to research those terms further.

That is all for now. I hope you can use something you learned here and apply them to your work. Thanks for reading!

Helpful links

Default values in JavaScript

Richard Torruellas — Sun, 29 Dec 2019 00:00:00 +0000

How I think about default values in JavaScript

First of all, all these things can fall under the Opinions, Concerns, and Nitpick umbrella. The most important thing is just giving thought to the things you have opinions about and always reserve the right to be corrected.

My simple rule of thumb is to try to set initial state to whatever the eventual state will be for Objects and Arrays.

Strings and numbers default to undefined.

Describing usage

Problems defaulting to undefined:

A lot of times I am just trying to describe how state will be used, so setting values that will be used later as undefined will give future users some understanding of what state might exist

// bad
const initialState = {
  // type string
  name: undefined,
  // type number
  age: undefined,
  // type array of strings
  cars: undefined,
  // type deep object {height: string, shoeSize: number}
  metaData: undefined,
}
// initialState.cars.map()
// > TypeError: initialState.cars is undefined
// console.log(initialState.metaData.shoeSize)
// > TypeError: initialState.metaData is undefined

Defaulting to undefined has been a safer choice overall in my experience, because other authors tend to not set object properties befefore usage, or they might just not exist on some JSON you get back from a server

Problems defaulting to null:

any time you want to use typeof you will need to check for two values. This is super error prone. typeof initialState.name !== "object" && typeof initialState.name === "string"

// Bad
const initialState = {
  name: null,
  age: null,
  cars: null,
  metaData: null,
}
// typeof initialState.name
// > "object"
// initialState.cars.map()
// > TypeError: initialState.cars is null
// console.log(initialState.metaData.shoeSize)
// > TypeError: initialState.metaData is null

Problems defaulting to the values type

const initialState = {
  age: 0, // is 0 a valid age?,
  name: "", // will someone typeof === 'string' and also have to check length?
}

Preference

My preference, which has in my experience been less error prone. The only time I will use null as a default is if some API I am using uses null, and that will be used in state.

It describes to future users what state will be availble
It is less error prone than other default types as described above
It does not limit the typeof operator
It does not tend to give as many false positives

const initialState = {
  age: undefined,
  name: undefined,
  cars: [],
  metaData: { height: undefined, shoeSize: undefined },
}
// typeof initialState.name
// > "undefined"
// initialState.cars.map()
// > works, no error
// console.log(initialState.metaData.shoeSize)
// > undefined