hjertnes.blog

#

19.12.2017 01:00

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.

setState

19.12.2017 01:00

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

18.12.2017 01:00

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.

https://gist.github.com/hjertnes/59cdc7efd773f6bb7015a0b49e557921

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

18.12.2017 01:00

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.

#

16.12.2017 01:00

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.

#

15.12.2017 01:00

#

15.12.2017 01:00

I was listening to the last episode of the Road Work this morning. Many people will probably not understand this, but I feel the same as John. I don’t really understand what “happy” is, and I never feel lonely.

#

15.12.2017 01:00

Anyone getting a iMac pro?

JSX

15.12.2017 01:00

JSX is the syntax we use to define markup with React. It combines Javascript code and markup together in a very flexible and powerful way and is without doubt my favourite thing about React. Everything you use in JSX that isn’t Javascript code, is technically components. All HTML tags are implemented as Components in React. For example the h2-tag is a h2 component inside the React package, with the appropriate params defined to a HTML attribute; note: they are not always the same though.

Everything that you wrap in HTML tags (either self closing or not) are components and everything inside curly braces are javascript code.

For example:

https://gist.github.com/hjertnes/6a858c42a5674e8e93b4d8d0bcae3e84

That would be a common starting point for a simple React app.

I personally think that JSX is the first templating system I have seen that is powerful, without adding a lot of syntax that isn’t plain Javascript and HTML. Most other ways to template I have seen almost turn it into a language of its own that let you combine code and markup.

The great thing about this is that almost everyone gets it straight away.

#

14.12.2017 01:00

Had this years last day at work yesterday. What’s the first thing I do when I get home? Started installing Arch Linux on my “new-old” Thinkpad.