hjertnes.blog

#

22.12.2017 01:00

I thought I would share this little tip right before the holidays. When I assume those of you that believe in New Years Resolutions are planning them.

When ever I know that I should do something about something that requires a lot of doing the same thing many times over. Like changing a lot of passwords or unsubscribing from newsletters etc, I often to this thing where I just add a repeating task for it. As a much more approachable and less procrastination prone way to do something about it.

Keys

22.12.2017 01:00

You have probably noticed that I have included keys on most of the examples where I list stuff. This is a very important part of writing performant react apps. They are not required, but recommended. The key should always be the same for one entity, I usually use the primary key of the entity I’m listing out. In other words: the key for one row should always be the same, so no random keys.

There isn’t much to the keys really. It is just a prop react use to keep track of what to do when a list of something changes. Is it a new entity? Did the entity change? Or was a entity removed. You don’t have to use them, but react will give you warnings in the console if you don’t, and you will notice the difference when you update large lists of things.

#

21.12.2017 01:00

I’ve been testing out the new “Sensei” driven auto-tune function in Lightroom CC for the last hour or so, and I got to say it’s pretty damn great.

The auto-tuning feature of Lightroom have been a lot of “swing and a miss” over the years. When I started to use Lightroom in 2013 I thought it was usually making my pictures worse. Then a year later it got a lot better. It didn’t always improve the pictures, but some times it did.

This new machine learning driven approach seems to be working great. All the pictures I have tested it on this far looks better, than they did. Not always by a lot, but still better.

Interacting between components.

21.12.2017 01:00

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:

https://gist.github.com/hjertnes/d62d883a708806d54691814bfbc92b27

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.

#

20.12.2017 01:00

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

#

20.12.2017 01:00

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

Refs

20.12.2017 01:00

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

https://gist.github.com/hjertnes/1577927e0cef8fb6b1a71a67d11e309c

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.

#

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.