Hjertnes.blog

#

December 31, 2017

React Component vs React PureComponent

December 29, 2017

I have mentioned the existance of PureComponent, and you’ll probably discovered sooner or later. There is a difference, but you should probably be able to safely use it wihtout any issues if you follow the kind of ideas I’m writing about on this site.

The core selling point of using a PureComponent is that it will cause fewer renders. This is achieved by doing a shallow comparsion instead of a full comparison. And fewer renders is a good way to improve performance without doing too much about it.

If you do a full comparison of props and state it will re-render every single time a single character changes. While a shallow compare will only trigger a update IF the address changes. You should probably find my article about value types vs reference types if you don’t understand what that means. The basic idea is that value types (numbers, strings etc) are values, which means that you are passing the value and not the variable itself around; while with a reference type you actually pass around the reference to the variable.

This means that React will check not the content but if prevState is in the same memory location as nextState; and the same goes for props.

Mirroing State to Props

December 28, 2017

Okay. So I don’t understand this one. But I have seen countless interns and other people try this really fucking dumb this. So I guess I have to say it: write the following a 1000 times on a white board

I WILL NOT MIRROR PROPS TO STATE UNLESS I HAVE A REALLY FUCKING GOOD REASON FOR DOING SO.

What I see them doing is that they send a:1, b:2, c:3 as props and then they set it as state. Before rendering it from state. Why? I have no idea. The result is that you’ll get an extra render for every time props change and a bunch of extra code.

The only situation where I see that it might be needed is if you recieve some data via props that you’re going to change in form.

Life Cycle Methods

December 27, 2017

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.

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>



<p>

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

</p>



<p>

  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.

</p>



<p>

  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.

</p>

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>



<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;

</p>



<p>

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

</p>



<p>

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

</p>

Unmount

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

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>



<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.

</p>

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.

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>



<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.

</p>

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.

PropTypes

December 26, 2017

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:

https://gist.github.com/hjertnes/004604e966cf37f52d4fbe0a59e51cd6

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

My camera kit.

December 25, 2017

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

December 25, 2017

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.

#

December 22, 2017

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

December 22, 2017

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.

#

December 21, 2017

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.