hjertnes.blog

In rotation

01.01.2018 01:00

I haven’t written about what I use and carry in a long time now.

The pens I carry change from week to week, but what I have with me today is my Pilot Vanishing Point, TWSBI Eco Stub and TWSBI Eco Broad. And I have my trusted Travelers Notebook with two lined refill, one Nock.co pocket sized notebook. And two Leuchtturm1917 A5 notebooks; one lined for writing and one dot grid for tasks and stuff.

My current ink is Diamine Sargasso Sea.

I’m mostly happy with my setup at the moment. There aren’t much I change, except for my ink every few months. But I do wish Leuchtturm1917 would expand the available colours available for their various notebooks. Because I would like to have different colours for the two notebooks I carry.

#

31.12.2017 01:00

#

31.12.2017 01:00

React Component vs React PureComponent

29.12.2017 01:00

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

28.12.2017 01:00

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

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>



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

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



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

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



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

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



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

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

PropTypes

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:

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

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.