Life Cycle Methods

27.12.2017 01:00

A React Component has a set of so called life cycle methods. They are a set of pre defined methods that are called when certain criteria are met. In the react world we use the terms “mounting” and “umounting”, it simply means mounted into to the DOM. Kind of like when you mount or unmount a disk.

There are five categories of life cycle methods: mounting, unmounting, error handling and other. All of them follow a naming convention that makes a lot of sense once you get used to it. If it contains “will” it will be called before and if it contains “did” it will be called after.

```text Mounting ```

contructor(). This is technically not a react method, but rather the same method all classes has. It is what is called when an instance of the class is initiated. This is the place you will set the inital state, bind various methods and so on. I usually also fetch data in the constructor. It takes props as its only argument. </p>


  componentWillMount(). This is the method that is called right before, rendering. It doesn&#8217;t trigger a re-render if you change state.



  render(). The render method is the only &#8220;required&#8221; method in a component. This is where you write what will be the output from the component.



  componentDidMount(). This method is called right after it is done rendering. If you don&#8217;t want to have your code for fetching data from backend in your constructor, then this is a good option. This is where I had them before I discovered class-based components.


```text Updating ```

componentWillReceiveProps(nextProps) is called when your component recieve new props. It is very useful if, for example you need to change something in state, when the properties change. For example you have a &#8220;Edit Blog Post&#8221; component, the id comes by props and you need to change the state for the new post. </p>


  shouldComponentUpdate(nextProps, nextState). This is a method called when react want to update, because state or props changed. You can use it to control if your component should update or not. It won&#8217;t update if you return false. To use this method should be a last resort, and I would make sure everything else is optimized, including using PureComponent instead of Component as a base before using this. And don&#8217;t do soemthing dumb like comparing with JSON.stringify in it&#x2026;



  componentWillUpdate(nextProps, nextState) this is called right before an update.



  componentDidUpdate(prevProps, prevState) this is called right after an update.


```text Unmount ```

componentWillUnmount() is called right before your component is removed. Do any required cleanup etc here.

```text willMount / willUpdate & didMount / didUpdate ```

The two pairs are kind of the same, you can&#8217;t call setState or anything in any of them, because that would be a incredibly dumb infinite loop. willMount is only called before the first render, and willUpdate is called before every render after the first; and the same goes for didMount / didUpdate, the only difference is that it is called after. </p>


  I almost never use them, but you use them if you need to do something in the DOM before or after render. Like hooking up or down some jQuery stuff for example.


```text Errors ```

componentDidCatch(error, info) was a very welcomed addition to React 16. If a exception is thrown in any component in it or anywhere under it, this method is called. This means that it is much easier to display a &#8220;Something went to shit&#8221; message and to collect errors with react. The old way used to be a white screen and a error in the console. Which was terrible.

```text Other ```

Then we have two methods left, setState and forceUpdate; I&#8217;m not going to talk more about setState, because we have covered it pretty well. forceUpdate on the other hand is a method where you can force React to re-render. </p>


  forceUpdate is a interesting beast. And while I see that there might be a need for it, I have never had it. This is one of the areas where I&#8217;m left with &#8220;are you sure there isn&#8217;t something else that is wrong here&#8221; feeling.


```text Summary. ```

The life cycle methods in React are very powerful, and you can use them to do more or less anything. A good advice from someone who has made more or less any mistake in the book: don&#8217;t override the update life cycle stuff unless you have to.


26.12.2017 01:00

PropTypes is one of the things you should get into the habit of doing sooner rather than later, kind of like keys, because it is harder to get into the habit the longer you wait. Proptypes is a way to define what kind of props you expect your components to get, what type they have and which of them are required.

It is an easy way, when you get it setup, to detect a lot of mistakes and stupid bugs.

For example:


If you look at the example above, it will show you how the two core selling points of PropTypes. The “children” prop is defined as a list and is required, this means that you will get a error if you try to use it without that props; while the defaultProps part lets you define default values. Which means the component will use the value “World” if you don’t specify it.

I think proptypes are awesome, and they are good for avoiding dumb mistakes, documenting your component and far more elegant than other ways of “defining” default values

Binder Clips

25.12.2017 01:00

Binder clips are probably my favourite “hack” to get page markers in notebooks that don’t come with them. They are dirt cheap and works great. I use them both with my Travelers notebook and my pocket sized notebooks to be able to find the first empty page as fast as possible.

I don’t use any fancy ones, just the plain black no-name ones you can find in any office supply shop. And I’ve had the same box for years.

They are durable, and stay put. My only complaint about them is that I wish I could find a version that was smaller and didn’t get stuck as easy when I take notebooks in and out of my bag.

My camera kit.

25.12.2017 01:00

My current camera kit or setup is a Fujifilm X-Pro2 with three lenses, A 8mm f/3,6 Fisheye, and two Fujifilm F2 lenses: 35mm and 50mm. The only thing I’m missing from it at the moment is a 23mm lens.

The fisheye is just for fun. And the 35mm is my trusty 50mm that I use almost all the time; and I have the 50mm for when I want to take portraits. The only thing I miss is something similar to a 35mm.

I could of course get a zoom lens that covers the area. But it would be slower and heavier. This is my the best thing about the Fuji F2 lenses (after the image quality) is how small and light they are. I have considered ditching my 50mm and getting a 56mm a few times. But the thing that always makes me stop, is how much heavier it is. It is basically twice the weight of the 50mm I have. This means that I could bring the 23, 35 and 50mm F2 + my camera body and my bag would weigh less than if I had my camera body + the 56 + the 35.

I might consider it, if shot more portraits.

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.


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:


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