Hjertnes.blog

#

January 25, 2018

<a href='https://hjertnes.blog/13c11d3f6e0648f2bf4915a02cf0ddb6-jpg/'><img class="img-fluid" width="150" height="113" img src="/13c11d3f6e0648f2bf4915a02cf0ddb6.jpg" class="attachment-thumbnail size-thumbnail" alt="" /></a>
<a href='https://hjertnes.blog/7ed3c4c460c545bab0f5fd9944886a5e-jpg/'><img class="img-fluid" width="113" height="150" img src="/7ed3c4c460c545bab0f5fd9944886a5e.jpg" class="attachment-thumbnail size-thumbnail" alt="" /></a>

Let’s see how this looks.

#

January 25, 2018

Picked up the diploma for my philosophy bachelor today, because going to the actual graduation sounded like torture. And it took me six months to pick it up, because I care more about the journey than the destination.

I’m still proud of the B I got in Wittgenstein studies though.

Optimizing React-Redux

January 25, 2018

If you need to tune React performance, I would guess, that most of the time it will be about render time. And there are many ways to deal with that. The basic idea is that you want to make sure you don’t do it too much, while still doing it when data change. My experience is that it is more about just re-rendering once when something change.

The best place to start is to make sure you use PureComponent instead of Component as a base for all of your components. And then make sure you connect your data from redux just where you need to. This means that you add the data exactly where you need it, and that you don’t send more data than needed.

And then I’d take a look at the following methods options in react-redux.

The react-redux Documentation:

When options.pure is true, connect performs several equality checks that are used to avoid unnecessary calls to mapStateToProps, mapDispatchToProps, mergeProps, and ultimately to render. These include areStatesEqual, areOwnPropsEqual, areStatePropsEqual, and areMergedPropsEqual. While the defaults are probably appropriate 99% of the time, you may wish to override them with custom implementations for performance or other reasons.

It will be overkill to do much with it in most apps, but all of the methods mentioned above containing “Equal” can be very useful to make sure that you only trigger updates when you need to. But don’t do it just to do it; the result will almost always be worse than the default. And tuning this kind thing is only for very special corner cases.

Testing Out Sunlit

January 25, 2018

2017-11-04

<a href='https://hjertnes.blog/8fd68974661d416690ffff0a2cec3b44-jpg/'><img class="img-fluid" width="150" height="100" img src="/8fd68974661d416690ffff0a2cec3b44.jpg" class="attachment-thumbnail size-thumbnail" alt="" /></a>

2017-11-11

<a href='https://hjertnes.blog/8a571765d95448ba9744f121fbeb2adc-jpg/'><img class="img-fluid" width="150" height="100" img src="/8a571765d95448ba9744f121fbeb2adc.jpg" class="attachment-thumbnail size-thumbnail" alt="" /></a>

2017-11-12

<a href='https://hjertnes.blog/4f819c369af54e1dbd809b5ed5768fa3-jpg/'><img class="img-fluid" width="113" height="150" img src="/4f819c369af54e1dbd809b5ed5768fa3.jpg" class="attachment-thumbnail size-thumbnail" alt="" /></a>

#

January 24, 2018

React Fragments.

January 24, 2018

As React have developed over the years, they have slowly removed redundant nodes from the HTML that React renders. For example, when I started something like this {this.props.value} would be wrapped with spans by React.

One of the awesome additions to React 16 was fragments, I think it went past most of us, because we were too busy testing out the new ErrorHandling and performance improvements.

Fragments solves a very pressing issue that most React developers will meet sooner or later. Every component only returns one root component. That means that you have to wrap a lot of stuff in unnecessary divs or spans to meet this requirement.

You can now wrap anything that you previously wrapped in divs just because of “React Reasons”, in either <> and </> or <React.Fragment> and </React.Fragment>.

The result is that you can have just one root element, without adding unneeded nodes to the dom.

#

January 23, 2018

I just got my invite to the Drafts 5 beta. Drafts have been one of my all time favourite iOS apps, I’m pretty sure I have used more or less every single point release of it. And I continue to enjoy it quite a lot.

The idea behind it is very simple: just start writing and worry about where it goes later. What makes it powerful is how you can define your own actions. In the past it was limited to url actions. While powerful, you were limited to sending the text to applications on your iOS device that had implemented a url scheme.

A url scheme is just a way where apps can define their own “protocol”, you could think of http:// as a url scheme claimed by Safari, 1Password used to have a 1p:// scheme (or something like that) in the old days to make it easier to open stuff in the 1Password in-app browser. This was way before extensions in mobile Safari.

Version five brings this to the next level by adding integrated support for talking to web services; this is done through JavaScript. This means that you could post directly to Micro.blog or your WordPress site instead of having to first send it to the WordPress app or Micro.blog app and then publish it from there.

It looks great, and I can’t wait. And it looks like more of the heavy lifting have been taken care of, compared to if you wanted to do something similar using Pythonista.

#

January 23, 2018