Forem: Marc Ziel

Declarative Programming in React

Marc Ziel — Thu, 26 Aug 2021 17:41:30 +0000

When you go to React.js front page you can read that:

Declarative.
React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

Then you look at some example:

function Square(props) {
  return (
    <button className="square" onClick={props.onClick}>
      {props.value}
    </button>
  );
}

and start to wonder how this code can be considered declarative? Is there any truth in the description? Let's find out.

Every app has state and logic. Logic can be expressed in declarative or imperative style.

People have different opinions about CSS language but everybody agrees that it's declarative, so we'll begin with CSS code and compare it to React code to see if there are any similarities.

This CSS code:

.trendy { color: red; }
.fancy { color: blue; }

can be translated to pseudocode:

when element class is `trendy` its text color should be red
when element class is `fancy` its text color should be blue

React expects similar declarative description from you:

//       declarative view description
//                   ↓
ReactDOM.render(<div>Hi</div>, rootEl);

The format of the view description that React uses is commonly known as VDOM and looks like this:

{
  type: "div",
  props: {
    children: "Hi"
  }
}

That's what JSX evaluates to.

The previous code snippet can be expressed in pseudocode as:

the view should be <div>Hi</div>

But this isn't really useful. We don't want our view to be static, that's why we chose React instead of just writing HTML code. We want something like:

when app state is `1` then the view should be <div>1</div>
when app state is `2` then the view should be <div>2</div>
...

Okay, the code it declarative but it isn't manageable (writing a clause for every possible number? No, thank you).

Can we do better? How about this code:

when component state is `n` then the view should be <div>{n}</div>

With just a single line of pseudocode we have all the numbers covered. This code is still declarative - it's equivalent to the previous pseudocode but a lot more succinct.

In CSS you can encounter special kind of declarations that are applied based on some data, like the position of an element.

Let's say you want every alternate div to have gray text, instead of writing:

div:nth-child(1) { color: gray; }
div:nth-child(3) { color: gray; }
div:nth-child(5) { color: gray; }
...

You can write:

div:nth-child(2n - 1) { color: gray; }
/* or even better */
div:nth-child(odd) { color: gray; }

Is there something similar in React? Well, yes - a component:

function Component({ n }) {
  return <div>{ n }</div>
}

It's a declarative function that describes the relation between the state and the view. So indeed, this is a declarative code. Whenever React needs to know how the current view should look like it fires up Component.

There you have it: React components are just like sophisticated CSS declarations and when you write in React, you're writing declarative code.

Create TLS / SSL Certificates for Local Development

Marc Ziel — Mon, 23 Aug 2021 14:51:14 +0000

When it comes to TLS certificates, there are a few tools such as mkcert to generate them but I like to proceed with caution.

The safest way would be to use openssl directly, but this is a low-level tool with many options that requires specific knowledge to use it properly.

The second best choice is to use the tool recommended by some authority in this area like let's encrypt so let's see what they suggest:

If you want a little more realism in your development certificates, you can use minica to generate your own local root certificate, and issue end-entity (aka leaf) certificates signed by it.

So I'm going to use minica here.

The tool itself is very easy to use, but first we need to build it from source (and probably take a look at the source code first). It's written in go, so we'll use golang container image:

# ./certs is the dir where we'll store certificates
podman run --rm -it -v $(pwd)/certs:/certs golang
# from the container; get the source code:
go get github.com/jsha/minica
git clone https://github.com/jsha/minica.git
# build binary file
cd minica && go build
# generate the certificates
minica --domains 'localhost,app.test,*.app.test' \
       --ip-addresses 127.0.0.1
# move the certificates to the mounted directory
mv minica.pem localhost/* /certs/
exit

The certificates should be in ./certs directory on the host.

Now we can add minica.pem to the browser we use for development. For Chrome-based browsers it's:
Settings -> Security -> Manage certificates -> Authorities

and use cert.pem and key.pem to authenticate the development server.

When we exited the golang container we destroyed it along with every file it contained, especially minica.key. This means that we won't be able to generate more certificates signed by this CA but if the file would fall into wrong hands it might be used against us for nefarious things like spoofing.

This allows us to have our dev server running on https (which means it closely resembles production environment) without decreasing the overall safety of our development machine.

Publishing a port on an existing docker container

Marc Ziel — Thu, 12 Aug 2021 15:36:43 +0000

When you need to publish some port on a container that was already run, you can do this by changing internal docker files.

First, you need to find the container id with

docker inspect <container_name>

Stop the container if it's running and go to the container directory:

cd /var/lib/docker/containers/<container_id>

For wsl users, the container directory can be found here:
\\wsl$\docker-desktop-data\version-pack-data\community\docker\containers

add "ExposedPorts" to config.v2.json:

"Config": {
    ....
    "ExposedPorts": {
        "<port_number>/tcp": {},
    },
    ....
},

and "PortBindings" to hostconfig.json:

"PortBindings": {
     "<port_number>/tcp": [
         {
             "HostIp": "",
             "HostPort": "<port_number>"
         }
     ]
 }

For best results restart docker service:

systemctl restart docker

Now you can start the container and it should have ports published.

How to reduce size of docker data volume in Docker Desktop for Windows v2

Marc Ziel — Sun, 08 Nov 2020 09:53:42 +0000

Docker Desktop for Windows v2, which uses WSL2, stores all image and container files in a separate virtual volume (vhdx). This virtual hard disk file can automatically grow when it needs more space (to a certain limit). Unfortunately, if you reclaim some space, i.e. by removing unused images, vhdx doesn't shrink automatically. Luckily, you can reduce its size manually by calling this command in PowerShell (as Administrator):

Optimize-VHD -Path c:\path\to\data.vhdx -Mode Full

The docker-desktop-data vhdx is normally in this location:

%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx

What is a container

Marc Ziel — Sun, 17 Nov 2019 19:59:54 +0000

You might know that a container is a standardized unit of software, that is, an application with everything that it requires to work: runtime, libraries, config, etc.

If this is not enough for you and you'd like to actually see with your own eyes what a container is, read on.

A container can be in two states: running or stopped.

In stopped state a container looks absolutely simple: it just one file called config.json that contains configuration and a directory called rootfs that is used as a container root (/) directory.

Can it be that simple?
You might know that a container image is basically just an archived directory that becomes the root directory when a container runs. We can unpack it with tar to a directory called rootfs:

mkdir rootfs && docker export $(docker create alpine) | tar -xf - -C rootfs

You can run a container with runc command after creating a default config file (config.json) with runc spec:

runc spec && sudo runc run mycontainerid

To see that you're indeed in a container, run:

cat /etc/*release*

and you should see NAME="Alpine Linux"
Moreover, if you start another terminal and create a file in rootfs directory:

touch /path/to/rootfs/hello-from-host

you'll see this file in the container:

ls /
# bin  hello-from-host  media

But what is runc and what does it do?

runc runs a container (that's basically what docker uses under the hood) in an isolated environment. Kind of.

What you might think is that runc puts an app process in a software equivalent of a solid metal box.

But it's far from truth. A container process is not enclosed in some kind of jail from which it cannot escape. The process has no idea that it's restricted. It has no idea how real world looks like. runc virtually lies to him that:

rootfs directory is the root of the filesystem
there are no other processes in the system and it's init process with PID 1.
about available network, computation and memory resources

It's more like putting a vr headset into a process without telling it that it's in virtual reality. It can't escape rootfs directory because in his world view rootfs is / and there's no way to go higher than /.

This is possible mostly thanks to two kernel features: namespaces and cgroups. namespaces allow to virtualize system resources and cgroups provides a way to limit resources like CPU and memory.

As you can see containers do not contain. The isolation is only one-way. A contained process can't see the world outside of a container but the host has all the information about the process, can access its filesystem and interact with it as if it was a normal process (it practically is a normal process). Isolation is based on providing fake information about the state of the system to a contained process.

That makes containers really lightweight but a little less secure than VMs. Moving a normal app to a container is a breeze because from the app's perspective there's no difference between normal environment and virtual environment presented to it when it's run in a container so there's no need for special modifications.

Summing up, a container is an app code and all its dependencies kept in a single directory tree plus a config file. When run, a container is restricted to that directory by making it think that the directory is a filesystem root and providing it with manufactured information about system resources. To make the container easy to transport it's packed into an image format that's basically an archive of a container directory.

Declarative vs Imperative - a Thoughtful Comparison

Marc Ziel — Wed, 26 Jun 2019 14:14:55 +0000

You might see a lot of people talking that declarative is better because it is simpler and give an example like this:

declarative code (what would you like):

a tea

vs imperative code (what would you like me to do):

- boil water
- pour water into a cup
- add a tea bag to the water

One short line of declarative code vs three long lines of imperative code. Evidently declarative must be better. But is this a fair example? What if we modify it a bit:

declarative code:

a tea

vs imperative code:

make a tea

Not much a difference, is it?
So, is declarative superiority just a hoax?
Spoiler alert: no, but if you want to know the real reasons, read on.

The basics

With declarative code, we specify what we'd like - the end result or state.
With imperative code, we specify a set of steps - an instruction that we'd like to be performed.

What are pros and cons of both? From a developer perspective, when looking at the code we are mostly concerned about what the code does (the end result), not so much how the code makes it happen (the steps). That's why we tend to put imperative code like this:

- boil water
- pour water into a cup
- add a tea bag to the water

into a module with a meaningful name like makeTea. This saves a bit of time and effort needed to figure out what that three lines are all about. With declarative code we declare the final goal so we have this feature inherently. That's a slight advantage of declarative code - we immediately know the end goal, with imperative code the end goal is implicit (it is there but we need to analyze the lines to get it or otherwise comment the code, or put it into a function or a module with a meaningful name).

The real advantage of declarative code is that it doesn't specify the starting point. With imperative code an initial state is implicit and mostly we start from scratch (which is the easiest way) like here:

- boil water
- pour water into a cup
- add a tea bag to the water

It implies that we are starting with cold water. What if we already had a hot water? It would get thrown away or would be boiled twice. A wasted effort.
With declarative code the system can be smart and reuse the resources it already has. The way of figuring out how to go from current state to the desired state is not our business anymore because we can't really specify the initial state in a declarative language - the state change is managed internally by the engine.

That's the real deal here:

With declarative, you specify the end goal and let the system work it out by itself.
With imperative you implicitly specify the starting state (or states if you want to be more resource efficient) by explicitly specifying a set of steps that lead to some final state.

What are some real-world implications of this?

Let's say we want some function that takes a string of HTML and renders it.
The easiest implementation would be:

const render = (html) => document.body.innerHTML = html;

The problem with this is that DOM is stateful, for example, the user might type something to an <insert> element and we want to preserve that. The above code doesn't care about what is currently in the <body>, it throws away everything and puts new content there.

You might've heard that React is declarative. In fact React render() function is declarative. It takes a description of how view should look like and figures out a way to make it happen. It is declarative because it takes a description as an input. It might work similarly to the code above - discard current content and replace it with the new one - but is much more intelligent and reuses the elements when it can.

That's the power of declarative. You only need to specify the desired state and let the system figure out how to get there. This is really important in places where resource reuse is important, where you can't just throw away everything and start from scratch like in DOM and network clusters because it takes this really hard problem of figuring out how to go from any state of the system to the desired state off your back.

increasing test timeout in jest while debugging

Marc Ziel — Sun, 12 Aug 2018 14:12:11 +0000

When debugging code, the script execution takes substantially more time which sometimes leads to very strange errors when an asyc test is failed due to exceeding the time specified in jest.setTimeout which causes the next test to execute while the previous test is still running in the background.

Fortunately, we can change the default time using --setupTestFrameworkScriptFile option that should point to a file in which we change the timeout:

jasmine.DEFAULT_TIMEOUT_INTERVAL = 10 * 60 * 1000;

We can put this file in the home directory and run jest with changed timeouts from anywhere with a little bit of command line magic:

node --inspect-brk node_modules/.bin/jest --runInBand --setupTestFrameworkScriptFile="${HOME}/test-setup.js"

Another cool thing is that if we also have a setup file in our project, both files are used (but values from file given through command line option take precedence).

vscode debug config for wsl and jest

Marc Ziel — Mon, 06 Aug 2018 21:48:35 +0000

When using the config from jest documentation the execution doesn't stop at specified breakpoints but the following config works with wsl:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Jest All",
      "program": "${workspaceFolder}/node_modules/jest/bin/jest",
      "args": ["--runInBand"],
      "useWSL": true
    },
  ]
}