Terminals Stitches and keys

Suddenly out of nothing I run on a blog post introducing a new terminal - Wrap. A few weeks ago I was wondering why we stopped having better UI for things in our Editors, and here comes better UI for the terminal. Nice validation. It has an impressive set of features. Being able to navigate when writing a command with multi-cursor support seems mind-blowing. Integrated autocomplete looks similar to Fig. Although collaboration features like shared sessions and chat, look good for remote pairing when problem-solving, I'm a bit worried that this will make this terminal expensive and subscription model.

Is it a viable idea to pay a monthly fee for a terminal? Or maybe the terminal will be free and one would need to go PRO for sharing? 🤔

The other reason discovering Wrap was interesting to me is that I found it the day after watching Casey Muratori's stream about refterm. His demo showcasing how fast terminals should be in rendering text, and why we shouldn't be so excited about Windows Terminal despite it's many features.

I don't do native desktop programming but I like Casey's explanations about the inner workings of the terminal, and the problems with APIs that he run into, and how he solved them. The results he got in a benchmark were mind-blowing.

The software can be fast... Who could know?

While speaking about terminals, having a nice prompt is almost as important.

I'm using Starship for quite some time, not because it's written in Rust. My main motivation was the out-of-the-box minimal design and its speed.

Before I was using oh-my-bash, but it was noticeably slow when showing Git info. Starship is much faster.

While traversing Twitter I've seen Dan quoting part of an article

And I cannot agree more with this. I had this thought some years ago. After reading the whole article I can also share how hard it is to convince others.

I had a similar discussion with colleagues resulting in still doing feature branching. For some reason, people prefer doing big Pull-Requests. Although I understand that having a top-notch Continues Delivery pipeline to support trunk-based development isn't something that comes easy and cheap.

I think that somehow we got so used to doing code reviews and working with branches, that we stopped remembering how we used to work without it...

Stitches is an interesting CSS-in-JS library that has a very small size and also is very performant. The most interesting thing about it is that it comes without a Provider, it doesn't need it.

The second key feature for me is that it has out-of-the-box support for design tokens.

Recently Pedro Duarte got interviewed by the CodingCatDev podcast and was talking about Stitches, as well as the whole CSS-in-JS trend, and the inspirations for it.

I'm a huge fan of the variant API, but the idea of using variants in combination with responsive styles as an alternative to media queries sounds very powerful and novel.

I use styled-system on the daily basis, which also has Variant API and responsive styles. Stitches look like the next step in evolution, more capable with better TypeScript support, smaller and faster.

The other day Dan wrote a blog post as a Twitter thread about React key prop.

Later someone asked Rich Harris how Svelte is handling those cases and he responded with a link to each docs.

Not surprisingly Vue also has a key attribute for the very same reasons.

Although there were few breaking changes between the versions.

As you can see all those frameworks have this form of an attribute. So learning from Dan's approachable explanation you learn not only React but also Vue and Svelte, in some way.

I like to watch some GDC presentations from time to time, learning about how to design games. YouTube algorithm presented me a talk from the Roguelike Celebration conference by Bob Nystrom about game architecture patterns.

Bob's explanation of ECS finally helped me understand the concept. Then he showed how ECS can be used to have composable capabilities for items. Like for a sword that has a ranged attack but also can throw a fireball and can be used to defend.

Bob also explains other code patterns in terms of solutions to problems you can run into while writing a game. Some of the patterns reminded me of how Fred George suggested writing Simple code.

The other day I was working with a big and nested type that was generated for me by Apollo based on our GraphQL schema.

I wanted to remove nulls which was quite easy to do with help of the build-in NonNullable utility.

I'm not a fan of the non-null assertion operator. It looks lazy and hacky and sometimes I'm just too paranoid to trust it.

NonNullable was great, but it doesn't work on objects, and just to remove one level of nulls I created one more utility.

type NonNullableObject<T> = {
    [P in keyof T]: NonNullableT[P]>;
};

This can be used in type predicate for array filter callback to remove elements with nulls.

The other challenge was how to get the type out of the array. I found two solutions. The first was to use a similar utility generic type to infer element type.

(Side note: Sadly I cannot find a good documentation for it, the best that search shows me is Inferring with conditional types)

type ArrayElement<ArrayType> = ArrayType extends (infer ElementType)[]
    ? ElementType
    : never;

Then I've stumbled upon the old post on How to get types from arrays that offer simpler solutions and dives into how it works.

I've created a small playground so you can see them side by side and choose whichever you prefer.