hjertnes.blog

The Shaddow DOM

25.12.2017 01:00

The biggest buzzwords surrounding React is “The Shaddow DOM”; I always think it sounds like something Sauron in Lord of The Rings could have made. It is the thing a lot of people believe will solve every problem they have with performance with their current setup.

The reality is that it makes some stuff faster, and there are good ways to solve most performance problems with React. But I think that you are probably not doing it like you should or in the most optimized way, if you have a lot of performance problems.

But, let’s get back to the shaddow dom. The DOM itself is what your browser parses a HTML file down to. And this is the object model Javascript interact with to add and remove elements. The shaddow DOM on the other hand is a copy of that. One of the most difficult parts of writing a javascript framework is to find the most efficient way to update the DOM. And this is where the shaddow dom comes in. WHen you components re-render React will update the shaddow dom, and then it figures out the most efficient way to propagate the difference between it and the real dom to the real dom.

#

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.