Interacting between components.

December 21, 2017

In general you don’t interact between components, because they should be independent. But you need to do it from time to time, especially if you aren’t using redux. For example if you have a todo app, and your TodoItem component have a delete button, and you need to tell the parent component to fetch data from backend and update the list of items. The way you typically do this when you don’t use redux is to send a update method as a prop; the function itself and not the result. For example:


The basic idea behind the example above is that, if you need to run code, in the context of the component above it, then you need to pass a function from it down to the child.


December 20, 2017

The snow and ice is melting and I couldn’t be happier


December 20, 2017

This ThinkPad with Arch Linux, Spacemacs and XMonad is awesome. It feels like a digital typewriter. No distractions, just writing.


December 20, 2017

Refs are a way you can do something with your child component. For example like in the example below:


Like you see in the example, I have made a method on the child component for changing the background color on the button, and I’d like to call that from the parent component. The way you do that is to give the component a ref as a prop. That will add it to the this.refs object, and give you the ability to call methods on the component. It can be very useful if you for example have a component with multiple sections of form values as seperate components and would like to have a Save all button in the root component.

Refs are useful when you need them, but I personally look at them as a “last resort”. I think that component should be as independent as possible; the parent should only know that “there are stuff here” and not too much about the different logic inside children. But again, they are very useful when you need it.


December 19, 2017

The latest version of Lightroom CC brings the file management features I was missing; it allows you to tell it to specify a location to store all of your originals that don’t count against the cache storage limit. In other words; it also brings a setting to store all smart previews locally. I think Lightroom CC is slowly turning into a much better version of Lightroom Classic.


December 19, 2017

It might look silly to have a seperate article about setting state. But some people are simply doing it wrong. And others are not aware of some of the more geeky details about the setState method.

The .setState method is how you change state in React. It takes either one or two arguments; one is what you want to update and the second is a optional callback to run after the state have been set. This is the thing I assume most people don’t know: state is set async. This means that: this.setState({foo: ‘bar’}); console.log(this.state) will not always or ever result with {foo: ‘bar’}. If you want to do something after the state have been fully updated, then you have to add a callback.

Let me get back to the first argument of setState; it can either be a object or a function returning a object. The object is what you want to change and not your entire state. If you only change one value, you only need to send that value.

One techincal detail at the end. When I say that setState changes state, this is technically not true, even though the result is that the changes you want are applied. What it does is to send a series of requests to update the state, and React figures out the most efficient way to do that. This is the reason .setState doesn’t immediatly update the state. And it doesn’t really change / mutate it, but it replaces it with a new object which is the previous one + the changes, something like this setState = (changes) => Object.assign(this.state, changes).

And a final note. I would try to limit the number of times you run setState, instead of calling it multiple times use a method to generate the changes. Because each time you run setState may result in a re-render; too much rendering is a certain source of bad performance.

Props and state

December 18, 2017

React is designed for data to flow in one direction. What this means is that a component doesn’t know what it is above it, and it can only communicate with what’s below it, if you take some specific steps to allow it. I’m going to touch on that in a later blog post. In other words, they are isolated from each other.

There are two different kinds of data that can trigger an update in React. It is props and it is state. Props are how you send data to components while state is how you store data that should trigger some kind of data when they update. For example when a list of blog posts change or in a form.

Props and state are two sides of the same coin. State is the internal data storage in React and props are how data are passed to components. And a React Component will re-render when either props or state changes.


If you look at the example above you’ll see a very typical seperation of concerns in a React App. You have a component responsible for fetching data and rendering a list — but not the items in the list. And then you have the list items in a seperate component. The list of blog posts is kept in state, becuase they will not be present when you load the component, but will be loaded into state as soon as the backend api request resolves. And then the list is re-rendered. The next step is to send the data to the post component. You do this by sending each thing as a “attribute” to the component.

Like I said in the beginner of this article; props are something you recieve, while state is something you set. This means that a component can’t change their props, but they can change their state. More on setting state in the next article.

The Perfect Lens

December 18, 2017

What is the perfect prime lens?

This is of course a very loaded question, and different people have very different opinions of what’s “best”. When I say “best” I should probably say “versatile”. If you get a SLR and only want one lens on that camera, what should you get?

If, you are going to use that camera for more than one thing, I think there are two very good options. A 35mm or a 50mm.

When I talk about focal lengths here, I do of course talk of them as if you were using a full frame or a 35mm camera. For example a 23 and 35mm lens on my Fuji would be the same as a 35 and 50mm on my 35mm analog film camera.

The 50mm is a classic, and probably the lens. And it have been so popular for a very important reason. It is wide enough to be able to capture your friends in front or you or landscapes. But still long enough so you need to work on your composition. And it is still long enough so you can use it for portraits, and get nice bokeh.

The 35mm on the other hand is awesome for shooting what’s in front of you without having to step too far back. For example when me and Ingri visit my parents, and I want to take a picture of all of them walking the dogs. With a 35mm I don’t need to be far back, but I would have to with a 50mm.

The biggest difference between the 35 and the 50, because both of them are excellent general purpose lenses, is the effect of bokeh. The wider the lens is, the less you see the bokeh.

I prefer my 50mm in general. It is the lens I have on my camera 90% of the time. But I like to use something wider, when I want to shoot groups of people without having to step back or being able to capture the whole of what’s in front of me. And if I’m just shooting portraits, I prefer something longer.


December 16, 2017

I’ve put together this super simple shell script to make it easier to update all your Arch User Repository packages: update-aur-sh. The big if is that you need to check out all the AUR git repo’s to one folder, and just change the script to reflect where you place them.

I kind of wish there were some better built in tools to manage AUR packages though.


December 15, 2017