Forem: Eldad Bercovici

I Built a Simple Serverless Storage Solution

Eldad Bercovici — Sun, 24 May 2020 08:01:18 +0000

Originally posted on my blog.

Looking for apartments in Tel Aviv is a drag.

Prices are high, demand is high and dealing with real estate brokers isn't fun. But most of all, Israeli websites (well, Yad2, the Israeli Redfin, is basically all we have) that help look for apartments are crappy as hell.

To keep as low friction as I could with Yad2 I wanted to create a bot that'll send me a message (on Telegram) whenever a new apartment that asnwers my criteria is posted. Bot available here.

Sending a Telegram message was pretty straightforward, and so was getting the data, the only thing that bummed me was that I had to set up a database, so that the bot will "remember" which apartments it had already sent me. I was looking for a free storage (well, database actually) service that was easy to communicate with and required as little effort as possible.

I couldn't find anything that was less than 3 clicks away, so I built one.

Introducing Cloud Local Stroage

Cloud Local Storage (CLS) is the outcome of that weekend's worth. It's a very simple DB, built on top of Firebase that is accessible through a Node SDK, web API and a commnad line tool.

Simply install it:

$ yarn add cloud-local-storage

And then, using a local-storage-like API, use it:

import cls from 'cloud-local-storage'

await cls.setItem('foo', { bar: 1 })
await cls.getItem('foo') // {bar: 1}

And that's it! Without the need to signup or start a database you are able to store & load data from the cloud.

Using CLS that way will store the data globally, meaning that if someone else calls cls.setItem('foo', {bar: 2}), they will overwrite your content.

To help with that you can either provide something more unique key than foo, or you could call cls.setItem without passing a key (passing only the data). When doing so, CLS will generate a key using uuidv4 and return it to you:

import cls from 'cloud-local-storage'

await cls.setItem({ bar: 1 }) // c6cd9316…
await cls.getItem('c6cd9316…') // {bar: 1}

Lastly, you can also namespace all your storaged keys under your account.

Creating Accounts

Cloud Local Storage also supports account based storages. Using CLS's commnad line tool you can sign up for CLS, you will then get a token, using that token you can store & load data under your account.

First install the CLS's command line tool:

$ yarn global add cloud-local-storage-cli

Then initialize it:

$ cls init

Follow the instuctions and after signing up the commnad line tool will save your token to ~/.clsrc.

Now you can use the SDK with your token:

import cls from 'cloud-local-storage'

const myStorage = cls('my-token-from-the-command-line-tool')
myStorage.setItem('userData', { a: 1 })
myStorage.getItem('userData') // {a: 1}

Space or Bandwidth Restrictions

Right now there aren't any space or bandwidth restrictions, but if it becomes pricey I might ask users to verify their account by phone beyond a certain usage threshold. The plan is to keep it free as long as I can and if it gets big find cheaper solutions (MongoDB, DynamoDb, etc...) or look for sponsership.

Anyhow, hope you find this useful.

Animating Route Transitions Using React Router

Eldad Bercovici — Sun, 05 Apr 2020 00:29:13 +0000

Originally posted in my blog.

Working on a side-project I wanted to create nice "flow"-y animations for when the user navigates between routes. Routes had to implement different "enter" and "leave" animations depending on which page the user navigates to and from, i.e., navigating from the Sign In page to the Home page animates differently (the Sign In page's leave animation) than from the Sign In page to the App page.

I ended up with a pretty neat Provider-and-hook duo that works nice with the popular React Router, so I thought I'd package it up nicely and share it.

See it live here.

react-route-transition

So react-route-transition is the outcome of that weekend's work.

The way it works is dead simple.

It exports a Provider you need to wrap your app with (place it inside of react-router's Router).

Behind the scenes, that Provider simply wraps its children (your app) with a Context Provider. It sets up the Context Provider, passing it a push (history.push, or react-router's push method provided by their useHistory hook) function, location (window.location, or react-router's usLocation() return value) and an (empty) array of listeners.

The two hooks provided by react-route-transition (useTransition() and useTransitionHistory()) will later read from and write to that context.

After wrapping your app with it, you can declare how your animations behave. To do so, you call the useTransition() hook.

Describing An Animation

useTransition() accepts an object the has a key named handlers whose value is an array of Handlers.

A Handler is an object that describes:

an animation
when to fire said animation

A Handler object is comprised of the following keys:

path - a string (or array of strings) specifying which path(s) the animation functions should fire when entering/leaving those paths.
onEnter - an async function that is fired once the user navigates to path. This one is where the animation code sits, it should resolve when the animation is done.
onLeave - same as onEnter, only this one fires when leaving path.

Here's an example of usage of useTransition():

useTransition({
  handlers: [
    {
      path: '/',
      onEnter: async () => {
        await gsap  // highlight-line
          .timeline()  // highlight-line
          .fromTo( // highlight-line
            '[data-home-main] > *, [data-home-footer]',  // highlight-line
            { opacity: 0, y: 20 },  // highlight-line
            { duration: 0.6, stagger: 0.125, y: 0, opacity: 1 }  // highlight-line
          )  // highlight-line
      },
      onLeave: async () => {
        await gsap.timeline().to('[data-home-main] > *, [data-home-footer]', {
          duration: 0.6,
          stagger: 0.125,
          opacity: 0,
          y: -20,
        })
      },
    },
  ],
})

When entering / start onEnter animation, when leaving, start onLeave.

When the component that called useTransition() unmounts, the handlers it registered are also removed, so pages no longer in view will not start animations in the background.

Now, if you're unfamiliar with gsap, it's an old school animation library from the 00's which is still really nice. A great, light-weight alternative is anime.js. They both expose simple APIs that make animating the DOM a breeze and (IMO) a lot more readable than declarative ones (see my disclaimer below).

What the first animation block (the highlighted lines) does is dim out (transition opacity to 0) all the children of the element that has a data attribute named home-main and the element that has a data attribute named home-footer. Each of the animated element will animate within 600ms and a staggering effect of 125ms will be applied.

The rendered element for such an animation might look something like:

return (
  <div>
    <main data-home-main>{/* this content will be animated */}</main>
    <footer data-home-footer>{/* some stuff here as well */}</footer>
  </div>
)

Awaiting gsap.timeline().to() means waiting for the animation to complete (its return value is then-able and resolves once it's done animating).

We are now ready to see the animation play.

Starting Up An Animation

react-route-transition will start an animation when the user navigates to (or from) a page for which an animation was required (in the example above, when the user animates to and from /).

The way you navigate pages with react-route-transition is same as with react-router, by calling history.push("/some-path"), except the history object here is the what's returned by useTransitionHistory(), a hook provided by react-route-transition.

react-route-transition handles navigating for you. It exports a hook named useTransitionHistory() that accepts the path you want to navigate to. That hook orchestrates the animations. It goes over the list of registered handlers, finds which ones describe an onLeave animation for the current location, fires up all these animations simultaneously, waits for them to complete and then calls history.push (react-router's), this causes new components to mount and register their handlers (that may or may not describe onEnter animations for this new view). Finally, it fires up all the onEnter animations for the new location.

2 Animations 1 View

Say you want one onLeave animation to start when the user navigates from the Sign In page to the Home page but a different one for when the user navigates from the same Sign In page to the App page.

You can do it by passing a from and a to options, instead of a passing the path option, for example:

useTransition({
  handlers: [
    {
      from: '/signin',
      to: '/app',
      onLeave: async () => {
        // Animation 1
      },
    },
    {
      from: '/signin',
      to: '/',
      onLeave: async () => {
        // Animation 2
      },
    },
  ],
})

Will start Animation 1 when leaving to the App page, and Animation 2 when leaving to the Home page.

Lastly, path, from and to also accept an array of paths. That's useful when you want the same animation to be fired when navigating to (or from) multiple pages.

Why Imperative Animations?

Personally, I don't like writing complex animations in a declarative manner. They're great for interactions, but I find that compared to animations written in an imperative way, the learning curve is steep, code readability suffers and playing around (just testing stuff out) is not as fun as the feedback loop tends to be longer. That may be because I started my way out as a Flash (ActionScript) developer, where tween animations were very popular, so don't take this as a fact. If you prefer the declarative approach keep at it and please let me know in the comments below, I'd love to hear about their upsides!

Enjoy a better development experience by enabling React Fast Refresh

Eldad Bercovici — Sun, 12 Jan 2020 21:12:40 +0000

Originally posted in my blog.

React Fast Refresh is the successor to React Hot Loader, a configuration option that lets you enjoy a (much) better development experience, by doing the following:

It listens to changes within your source files and sends them, and only them, to the browser (or mobile device, for React Native). When those changes arrive at the browser, the code segment that has changed is being "injected" into its module, replacing the previous code. If that module is able to accept said changes without having to reload the page, then your app gets updated without losing its state.

In other words, when you hit Save, instead of refreshing the page, React Fast Refresh will only reload the components affected by the change.

Dan Abramov (and others) have recently re-wrote this feature, renaming it React Fast Refresh. It was initially out for React Native, while React developers were promised a similar experience. Finally, it seems like the days of waiting are over¹ and, while it's still in development, you can now try it out in your Create React App (without even ejecting).

Trying React Fast Refresh

Create React App, out of the box, does not yet support Fast Refresh (as it's still under development and may still contain some bugs). That means we either have to eject and modify Create React App's config files or use a little magical tool called react-app-rewired.

React-app-rewired lets you:

Override create-react-app webpack configs without ejecting

That's it. It's pretty cool since you can do some useful things with it, like including component names when using styled components, adding a webpack.DefinePlugin block to your config, and many more.

It's important to take into account that react-app-rewired is "lightly" maintained (mostly by the community), or as Dan Abramov somewhat officially tweeted: "Stuff can break".

So with that, let's add it to our project!

Adding React App Rewired

In order to add react-app-rewired to our project, we start by installing it:

$ npm install react-app-rewired --save-dev

We then create a config-overrides.js file, next to our package.json:

/* config-overrides.js */

module.exports = function override(config, env) {
  // do stuff with the webpack config...
  return config
}

And finally, modify the scripts section of our package.json:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test --env=jsdom",
  "eject": "react-scripts eject"
}

That's it for react-app-rewired. We are now ready to enable React Fast Refresh.

Enabling React Fast Refresh

To do that, we'll install two packages:

customize-cra, which is a set of utility functions that help modify config objects. It exposes functions like addBabelPlugin and addWebpackPlugin which are necessary for our second package to work,
customize-cra-react-refresh, this is the one that makes the necessary changes to Create React App's config files in order to get React Fast Refresh to work.

We'll install both of them:

$ npm install -D customize-cra customize-cra-react-refresh

Leaving us with the last and final step of modifying the config-overrides.js file we created above:

/* config-overrides.js */

const { override } = require('customize-cra')
const { addReactRefresh } = require('customize-cra-react-refresh')

module.exports = override(addReactRefresh({ disableRefreshCheck: true }))

And we're done! We can now restart our development server and enjoy a greatly improved feedback loop and overall developer experience within our Create React App.

Disclaimer: I haven't thoroughly tested React Fast Refresh yet, I was very excited to find that it's ready to test out and wanted to share it. I will probably update this post in the coming days, adding the caveats I'll find along the way.

¹ If you don't mind a few hiccups here and there...

Optimizing Webpack's build time by learning from the best

Eldad Bercovici — Sun, 05 Jan 2020 22:07:43 +0000

Where I work at (a small-medium startup called Spot.IM) we use Webpack to bundle our products. After about 4 years and who knows how many hands contributing to the source code, our main product's build time reached a staggering 90 seconds for initial build and 14 seconds for re-build.

That's 14 seconds you had to wait every time you hit save.

Applying some easy wins which anyone can introduce to their stack we were able to slice those numbers down to 20 seconds for build and 1 second for re-build.

In this post I will go through some simple changes you can make to improve your bundle's build time.

Note: If you are using Create React App (or any other fancy app generator) this post probably won't matter that much to you, if not it might help a lot, so keep reading!

Measuring Success

Before we do anything, let's set up a way to measure our improvement. To do that we'll use a tool called speed-measure-webpack-plugin:

const webpackConfig = require('./webpack.config')
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin')

const smp = new SpeedMeasurePlugin({
  disable: !process.env.MEASURE,
})

module.exports = smp.wrap(webpackConfig)

We wrap the Webpack config file with SMP (which we enable through an environment variable), later we pass that config object to Webpack, which will then print a nice report specifying each loader's processing time per each build. This way we win in two frontiers, one is that we get immediate feedback to our optimization attempts and the other is that we instantly get a full report of how long each loader (or actually "chain of loaders") took:

Improving Initial Build Time

After setting up SMP, we can start seeing how our build time changes as we make improvements, the first thing we'll tackle is the initial build time (i.e., the time it takes for Webpack to bundle our package since it has been initialized), we'll use a loader called cache-loader to do that.

Cache-loader is a Webpack loader that caches the results of loaders preceding it on disk (or database). Meaning the next time you run Webpack you'll (hopefully) see a significant improvement.

Set up example:

{
  rules: [
    {
      test: /\.jsx?$/,
      use: [
        'cache-loader', // highlight-line
        'babel-loader',
      ],
    },
    {
      test: /\.scss$/,
      use: [
        'style-loader',
        'cache-loader', // highlight-line
        'css-loader',
        'postcss-loader',
        'sass-loader',
      ],
    },
  ]
}

Adding it before css-loader (for CSS) and before babel-loader (for JS) we were able to shave off around 75 seconds from the initial build time.

Now let's tackle the re-build time, to do that we'll modify a property called devtool.

Webpack Source Maps

Within Webpack's configuration you'll find something called devtool, which according to the docs lets you:

Choose a style of source mapping to enhance the debugging process. These values can affect build and rebuild speed dramatically.

In other words, modifying it will change what type of source maps you'll get, and more importantly, how long you'll have to wait until you get it.

Playing with this one was a life changing experience. I really can't emphasize this enough. We changed it from source-map (which is possibly the slowest one) to eval-source-map and were able to improve our re-build time from 14 seconds down to 3.5 seconds.

{
  devtool: process.env.NODE_ENV === 'development'
    ? 'eval-source-map'
    : 'source-map'
}

There are 12 different variants, Create React App uses cheap-module-source-map, so play with it and see what's good for your needs.

What you lose here is the quality of the source maps generated, and you feel the degradation once you start debugging the code. Luckily, browsers right now are keeping up the pace with TC39, so (at least while developing) you don't really need to transpile a lot of your code. If you set Babel up so that it will transpile Javascript to the latest browser version (as CRA does) you should be fine, as the source maps won't be too far off from the code itself.

Here's how your babel.config.js should look like should you want to transpile to the latest browser versions:

module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        targets: [
          'last 1 chrome version',
          'last 1 safari version',
          'last 1 firefox version',
        ].join(', '),
      },
    ],
  ],
  // ...
}

And that's it. 3 simple steps and our build time decreased significantly. Next time I will share how we later added Hot Module Replacement, a configuration that helped save precious time and improve the feedback loop we experience while developing.

Learn From The Best

When approaching such a task, the first idea that comes to mind is to delve in Webpack's docs and see what we could find. But it's not the only one.

A different approach I found, that has really proven itself, was to go through webpack.config files of existing open source projects. Specifically, Create React App's one. There's a lot you can learn from it.

I will definitely keep this approach, of learning from the best, in mind in future tasks.

Wait, You Said 1 Second.

You're right!

We were able to slice 2.5 more seconds, but it was by making a bunch of changes that were very domain specific, where the domain I refer to is our (Spot.IM's) needs. So sharing them down here just doesn't make much sense.

Dependencies:
speed-measure-webpack-plugin
cache-loader

Yet Another List of (lesser known) VSCode Extensions

Eldad Bercovici — Sat, 04 Jan 2020 07:13:56 +0000

VSCode is one hell of an editor. About two years after it was initially announced I started using it regularly, and, as much as I cherish Sublime Text, I haven't looked back since.

Here are some of my favorite extensions.

Naming Is Hard

Naming things is one of the toughest problems I encounter daily while programming.

A lot of times I would google the not-so-good name I came up with just to see what comes up.

Altervista Thesaurus, Cinnanyms and Dictionary Lookup all try solving this issue by listing synonyms of whatever word you give them.

It's nice and it helps some of the time. But sometimes the word I'm looking for isn't an equivalent of some word. Sometimes I'll think of a word, and I'll want to know what is it a type of. For example, the word "example" is a type of "representation". For that, I'll use Words API. No VSCode extension for it yet.

Editing Utils

Change Case - It has been in my toolbelt since I've been using Sublime Text. I am using it so much that I've set up the following keybindings for it:

[
  {
    "key": "cmd+i cmd+k",
    "command": "extension.changeCase.kebab"
  },
  {
    "key": "cmd+i cmd+c",
    "command": "extension.changeCase.camel"
  },
  {
    "key": "cmd+i cmd+p",
    "command": "extension.changeCase.pascal"
  },
  {
    "key": "cmd+i cmd+s",
    "command": "extension.changeCase.snake"
  },
  {
    "key": "cmd+i cmd+t",
    "command": "extension.changeCase.title"
  }
]

Expand Region - This one lets you bind a keyboard shortcut for expanding and contracting the selected region, having a GIF explain it makes so much sense, so check out the one in the link.

I found the following keybinding best suiting for it:

[
  {
    "key": "alt+shift+up",
    "command": "expand_region",
    "when": "editorTextFocus"
  },
  {
    "key": "alt+shift+down",
    "command": "undo_expand_region",
    "when": "editorTextFocus && editorHasSelection"
  }
]

Import Cost - Displays the size of an imported 3rd party module, next to the import statement. Doesn't always work for me, but when it does it's really neat. Saves the hassle of going to Bundle Phobia.

Incrementor - Lets you bind a keyboard shortcut to increment/decrement the value within your current selection(s). I used to havily depend on this one but haven't much since I moved to VSCode. Maybe you'll find it useful though.

Insert Numbers - Insert a range of numbers to all cursor positions.

Multiple Cursor Case Preserve - Got a curser over a bunch of words cased differently? Once you start typing, this extensions will preserve the casing under each selection. I use this one a lot!

Path Intellisense - Autocompletes paths as you write them.

Permute Lines - As the name suggests, this one exposes some nice line manipulation tools.

Select Part Of Word - This one lets you traverse camel-cased words easily.

I have the following keybindings set up for it:

[
  {
    "key": "ctrl+shift+right",
    "command": "selectPartOfWord.selectRight"
  },
  {
    "key": "ctrl+shift+left",
    "command": "selectPartOfWord.selectLeft"
  },
  {
    "key": "ctrl+backspace",
    "command": "selectPartOfWord.backspace"
  },
  {
    "key": "ctrl+delete",
    "command": "selectPartOfWord.delete"
  },
  {
    "key": "ctrl+left",
    "command": "selectPartOfWord.moveLeft"
  },
  {
    "key": "ctrl+right",
    "command": "selectPartOfWord.moveRight"
  }
]

Diff

Partial Diff - VSCode has a nice UI for diffing files. This extension lets you enjoy that UI when diffing between a wider variety of input sources (files, clipboard and current selection), so you can diff between the contents of your clipboard and your current selection, for example.

Files

Copy File Name - Useful in projects where the filenames are the names of the classes/functions they contain. With it I can Cmd+Shift+P > Type "cfn" > Enter, then paste it somewhere I need it, and using the kybindings for Change Case, change its case to whatever.

File Utils - This extension adds some useful file manipulation commands to the Command Palette.

Etc

Copy JSON Path - Very useful in all sorts of use cases. One that pops to my mind immediately when thinking about this extension is where you need to specifiy the getter string (or JSON path) for an i18n string that resides in some lengthy JSON.

Quit Control for VSCode - Quit control will pop up a message box making sure you really want to leave once you hit Cmd+Q / Cmd+Shift+W. This one saved me so many times.

More Shortcuts

Coming from Sublime Text, I'm pretty sure the first extension I added was Sublime Text Keymap and Settings Importer (check this out for even more extensions for people coming from ST).

Here are some other useful keyboard shortcuts I set up along the years:

[
  // Collapses all folders within the Explorer Pane
  {
    "key": "cmd+k cmd+c",
    "command": "workbench.files.action.collapseExplorerFolders"
  },
  // Cancels the default binding for cmd+k cmd+r
  {
    "key": "cmd+k cmd+r",
    "command": "-workbench.action.keybindingsReference"
  },
  // Binds cmd+k cmd+r to refresh the Explorer
  {
    "key": "cmd+k cmd+r",
    "command": "workbench.files.action.refreshFilesExplorer"
  },
  // Again, clears existing keybinding (ctrl+t)
  {
    "key": "ctrl+t",
    "command": "-editor.action.transposeLetters",
    "when": "textInputFocus && !editorReadonly"
  },
  // Binds ctrl+t to Git Create Tag
  {
    "key": "ctrl+t",
    "command": "extension.gitcreatetag"
  },
  // Close all editors to the right of the current one
  {
    "key": "cmd+i cmd+r",
    "command": "workbench.action.closeEditorsToTheRight"
  },
  // And, for completeness, the not so useful close-editor-to-the-left
  {
    "key": "cmd+i cmd+l",
    "command": "workbench.action.closeEditorsToTheLeft"
  },
  // Clears the terminal
  {
    "key": "cmd+k cmd+k",
    "command": "workbench.action.terminal.clear",
    "when": "terminalFocus"
  },
  // Increase and decrease the sidebar's width using your keyboard!
  {
    "key": "ctrl+shift+left",
    "command": "workbench.action.decreaseViewSize",
    "when": "sideBarFocus"
  },
  {
    "key": "ctrl+shift+right",
    "command": "workbench.action.increaseViewSize",
    "when": "sideBarFocus"
  },
  // The following ones map Chrome's DevTools keybindings to VSCode's debugger
  {
    "key": "cmd+'",
    "command": "workbench.action.debug.stepOver",
    "when": "debugState == 'stopped'"
  },
  {
    "key": "f10",
    "command": "-workbench.action.debug.stepOver",
    "when": "debugState == 'stopped'"
  },
  {
    "key": "cmd+;",
    "command": "workbench.action.debug.stepInto",
    "when": "inDebugMode"
  },
  {
    "key": "f11",
    "command": "-workbench.action.debug.stepInto",
    "when": "inDebugMode"
  },
  {
    "key": "shift+cmd+\\",
    "command": "workbench.action.splitEditor"
  },
  {
    "key": "cmd+\\",
    "command": "-workbench.action.splitEditor"
  },
  {
    "key": "cmd+\\",
    "command": "workbench.action.debug.continue",
    "when": "inDebugMode"
  },
  {
    "key": "f5",
    "command": "-workbench.action.debug.continue",
    "when": "inDebugMode"
  }
]