08.01.2018 01:00

The official Context API documentation says that it is experimental, and that you should avoid using it. I don’t use it, and I have never done so with anything that is in production. I personally think that using for example redux solves many if not most of the problems that most people try to solve with the Context API.

I’ll explain what it is, and what it does, even though I don’t recommend it at the moment.

Context is a second way to pass data between components. It got a lot more attention when I started to learn react. The reason is that the API never was stable enough to be worth the hassle to be honest. What Context tries to solve is the problem of passing data through components structures without having to pass the prop through every single Component.

Let’s say you have Five components nested under each other.

Like this: Comp1->Comp2->Comp3->Comp4->Comp5, and you have a element in Comp1 state, that tells what kind of colour the button in Comp5 should have. You define a “getChildContext” method in Comp1 that returns an object which is the context, and then everything under that component may access the context through this.context.

As of React 16 aka fiber the Context API is broken. There is a api for updating the context, but it is broken. It might be because it will be deprecated or because it will be fixed in some future release. I personally think that redux solves most of these problems, because you can pass props to any component anywhere in your code base without going through deep component structures.


08.01.2018 01:00

I finally got my invite to Micro.blog in the end of October. And I got to say: it’s awesome.

Micro.blog feels a lot like what App.net felt like, and a lot like Twitter in the old days.

I would encourage everyone that miss those times to check it out. It feels very beta at the moment, but it will get there.

Two years have passed.

08.01.2018 01:00

There aren’t many things I’m worse at than keeping up with anniversaries and stuff like that. Part of the reason is that I write most of the post from a few weeks to a few months before they are going live, so I have little to no connection to when something will be live. That has the added benefit of me doing everything I can to make them have as little connection to “right now” as possible.

By the time this goes live I would have written this blog for over two years. A lot have happened over that time. These days I’m more or less happy with the kind of stuff I’m using. And the main area of experimenting is new inks. I might try a couple of new notebooks a year, and I only get new pens when I see something I don’t have in some pen I discover.

I guess I have moved over to what I really wanted this site to be about. Writing more about using the products, than the products themselves. And how to go about figuring out the perfect stuff for me. Rather than reviewing all the Lamy Safari or TWSBI colors.

What if I actually manages to schedule this post for the real anniversary next year?


05.01.2018 01:00


05.01.2018 01:00

Building forms using React can be a little bit of a hassle until you get used to it. Some use thrid party tools to make it less cumbersome. I personally think that the default is good enough.

The way you build forms is to have a state element for each “thing” in your form, and then you need to write updater methods and methods to deal with every other event you need to deal with.

It isn’t difficult, but there are a few stumbling blocks along the way. D not write your code as anyonymous code, write them as functions either arrow or regular in your component class, because it will slow down the rendering. I personally use arrow functions to deal with the rendering, because I don’t need to bind them.

You could of course do something like this

const update (key) => { return (e) => { let o = o[[][key]] = e.target.value this.setState(o) } }

But I suspect it will be more code than the usual updater

updateUsername = e => this.setState(value: e.target.value)

It depends on how much other stuff, if any, you need to do.

There are some libraries out there that claims they make it easier. I personally have not seen anything that I think is worth the hassle.

Building forms with react can be a lot of extra code. And you need state for each one, and a updater for each one. But you have full control of what’s going on with each form element. And I personally think it is far easier to debug forms using react than some other systems I’ve used where they try to be smart.


04.01.2018 01:00

I have deleted twitter from all of my devices, and I have signed out of Facebook on all of my devices. Let’s see how long this experiment last.


04.01.2018 01:00

Composition is a very important concept to understand if you are going to write good and maintainable react code. Because React components can be nested. What this means is that you can write a component where you say “place everything nested under me here”. You do this by using the children property.

You might have a component for the basic layout of your app, and then you place the router under it, telling it where you want the content to go.

This is a very powerful way to write re-usable code; where you want some to have the same stuff surrounding various different types of content.

Composition and Higher Order Components are the techniques I think are the reason you can write a lot more with a lot less lines of code using react; if you do it right.

Higher Order

03.01.2018 01:00

Higher order functions or components is one of those ideas that have had a huge influence on how I think about solving problems. I have written about it in the past, but the basic idea behind them is that a Higher Order X is a X that will return a X or takes one or more X as a argument.

For example: a function that takes a function as a argument or returns a new function; or a component.

Note: it returns a actual function or takes a actual function as a argument, and not the result from a function.

This is for example anything with a callback works in Javascript.

I assume the passing function / components as arguments is the easiest to understand concept out of the two. Like I mentioned above, it is a way to re-use the same code without adding a lot of complexity to the code. Let’s for example say that you have a lot of components that show a list of “stuff”. And it also needs to have a way to fetch the data.

The way you could solve this is to add a lot of if / else to solve it; or you could use higher order to solve it. The latter is easier to maintain, extend and use.

I would solve this by passing a “fetch” or “update” function to the list component, plus a item component; both as props. This means that the component would run this.props.fetch to load stuff, and use this.props.item to render the items in the list. And it would be easy to extend to manage editing and deleting, because you only need the logic in the list component and all you need to do in each use of it is update delete and save functionality.

The other type is a little bit harder to grasp. But as I said, the basic idea is that a function returns a function and a component returns a component. Let’s say you need to implement a check to validate if the user is authenticated. You could add some code to check it, all over the place, or you could wrap it with a higher order component. Where the logic for testing and telling you that you don’t have access is in one place and you just call it with your component as a argument to get them wrapped component back.

This is by the way how the redux connect() method works; the method you use to connect state from redux to component props.


Look at the example above, I haven’t actually tested it; but it shows the basic idea. You have a generic “list” and a generic “item”.

You pass what “item” to use, and what update and delete methods to use to the parent; and you could use some like the example above for listing out more or less anything. The only thing that would change would have been the update methods, and you could even add extra “item” components as needed.

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.