hjertnes.blog

Micro.blog

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

Forms

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.

Composition

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.

https://gist.github.com/hjertnes/2b3675640c8c29978b7b69acd94cddb7

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.

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