Don’t do this

02.01.2018 01:00

Session storage is a key value store in the browser, that can be used for temporary storage in JavaScript apps, per tab / window / session. It used to be a very useful technique in the “old” days. I have seen some people use it instead of redux or react’s built in state for some strage reason. And I think it is a bad anti-pattern. Because of various per browsers limitations, and you miss all of the nice things about redux / react state.

If you think you need it, I would look into why. Because if to make it easier to pass data between components, then I would look into redux.

Analog photography.

01.01.2018 01:00

I have written about analog photography a lot. And I will probably continue to do so.

Some people love it, other people hate it. And some people have the same kind of feelings about digital photography.

I love both. The fast iteration of digital makes it possible to learn a shit load in just a single weekend. While bare minimum of analog photography makes it very enjoyable. But I believe that everyone will become much better photographers if they spend time shooting with a fully manual camera. Without anything but a meter. All of us understand how the various settings of our camera affects each other. But you will understand it much better, when you have to do it all yourself.

You need to shoot in manual, if you want to master exposure. One option is to set your digital camera to manual. But I thought it was much easier to do it with a analog camera from the late 70s. Because it is designed for shooting this way, while the only modern cameras that are designed for this come from Leica and Fuji. And because you don’t have the option of turning stuff back on.

You will understand what auto focusing and your camera meter are doing. And you will realize that the exposure doesn’t need to be spot on. Same goes for focusing; unless you’re shooting wide open.

I think shooting analog have had a bigger impact on my photography than most of the books I’ve read.

Different kinds of components

01.01.2018 01:00

All the components you have seen up this point, in this blog post series, have been of the regular React type; either based on Component or PureComponent. There are two others.

One of them are the “old-school” React.createClass, which is now deprecated. This is how React Component were defined before the “class” keyword in Javascript. It does more or less the same as if you use the class based component, only that the syntax is a little bit more “weird”.

The last kind is stateless functional components. They look like this:

https://gist.github.com/hjertnes/06b1d359c922b4a0d210069625cb5e50 ` The functional components are useful; and a highly controversial topic among some. The easiest way to understand them is to think of them as a component only being the render method. It will re-render every time the props change. And they don’t have any life cycle or state. I think they are useful for a number of reasons

  • ```text Fast to write ```
  • ```text Minimal overhead ```
  • ```text Easy to write a series of re-usable components ```
  • ```text You really consider if you component need state. If so, it would require a re-write. ```


    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


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

    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.