Are you also tired of jumping from one project to another and sometimes you need nodejs 14, sometimes you need nodejs 16, and sometimes you need nodejs 18.

I feel the same way and I know it's just a command with ```nvm``` or my personal favourite ```n```.

But what if you go into your project and the right node version is always there?

That was my wish too and I have fulfilled it.

### What do you need
- [node](https://nodejs.org/de) (hope this is already installed)
- [nvm](https://github.com/nvm-sh/nvm) or [n](https://github.com/tj/n) 
- [zsh](https://ohmyz.sh/)
- [node-package-version](https://github.com/tzdesign/node-package-version)

If you install my tool, you can get the right node version directly with npv fix.

### Installation

```bash
npm install -g node-package-version
```
or 
```bash
yarn install -g node-package-version
```

Then simply add the following part to your ```.zshrc```:

```bash
precmd(){
    npv fix
}
```

Now just press enter or open a new terminal in the project and the script runs and selects the correct node version.



Node version via package.json 

How 10 Engineers Deliver Exactly What the Browser Wants with Qwik

Even in Qwik you sometimes need more complex components that need to be rendered both as a link and as a button or whatever element.

## QwikIntrinsicElements

The type QwikIntrinsicElements is the base you should rely on here.
The Qwik team has extended the **HTMLAttributes** here.

What can your props look like now? As the title suggests, we can't get around generics.

For my button component, the props look like this:

```tsx
export type ButtonProps<C extends keyof QwikIntrinsicElements> =

QwikIntrinsicElements[C] & {
	as?: C;
};
```

**C** is then the prop that decide what props are used from QwikIntrinsicElements.

The implementation for this is then altogether the following:

```tsx
import type { QwikIntrinsicElements } from '@builder.io/qwik';
import { component$, Slot } from '@builder.io/qwik';

export default component$(
  <C extends keyof QwikIntrinsicElements>(props: ButtonProps<C>) => {
    const Component = (props.as ?? 'button') as string;
    return (
      <Component>
        <Slot />
      </Component>
    );
  }
);

export type ButtonProps<C extends keyof QwikIntrinsicElements> =
  QwikIntrinsicElements[C] & {
    as?: C;
  };

```

You are welcome to add your own props under ``as?``.


## Casting as string

```tsx
 const Component = (props.as ?? 'button') as string;
```

Unfortunately there seems to be no clean carry over for the key into JSX yet. I have experimented quite a bit and worked with ```keyof QwikIntrinsicElements``` etc. I had first worked with ```any```, but since I'm sure many of you use Prettier and Lint, I find string a bit more appropriate here.

Much easier than in React, where you always have to think ```forwardRef``` as well.

Have fun with Polymorphism



qwik polymorphism

Who would have thought it, but there is an alternative to ``parseInt`` and ``parseFloat`` to work with user input.

```tsx
<input type="number" onChange={(event) => {

console.log(event.target.valueAsNumber)

}} />
```

As if that's not enough Good News, there's also valueAsDate:

```tsx
<input type="date" onChange={(event) => {

console.log(event.target.valueAsDate)

}} />
```
    
More info can be found on the [Builder.io Blog](https://www.builder.io/blog/numbers-and-dates).

HTML Input ValueAs

You surely know this, you write a function and at the end you have several blocks IF-ELSE.


Sure, it could be that your programming style is a bit **dirty**, but maybe you are just working with a language that doesn't support guard like Typescript/Javascript.

Here is an example of what kind of code I mean:


```typescript
function getClassNameByNumber(number: number): string {
  if (number > 100) {
    return "dark";
  } else if (number > 50) {
    return "medium";
  } else {
    return "light";
  }
}
```



## Fallthrough switch

Of course, you can probably also use a switch for many of these functions:


```typescript
function getClassNameByNumber(number: number): string {
  switch (true) {
    case number > 100:
      return "dark";
    case number > 50:
      return "medium";
    default:
      return "light";
  }
}
```

## guard-style in javascript

But if you use some kind of **guard-style** code, it is much easier to read:

```typescript
function getClassNameByNumber(number: number): string {
  if (number > 100) return "dark";
  if (number > 50) return "medium";
  return "light";
}
```
## The real guard statement in swift

Attention, guard is a kind of negative IF. Therefore the logics are reversed here. Only if the guard-statment is True, the function continues.



```swift
func getClassName(for number: Int) -> String{
    guard number < 100 else { return "dark" }
    guard number < 50 else { return "medium" }

    return "light"
}
```

## Conclusion

I think that this kind of queries are much more readable. Of course you should keep functions as small as possible and in the last return statement you should always keep the most important data based of the return type.

Especially in Swift, I don't want to give away the guard statement anymore.

Use guard statements over else-if

Tobias Zimmermann

software architect and interaction designer

amplify console

amplify-cli

apache

apollo-client

apollo-server

aws-lambda

aws-rds

canvas

docker

enzyme

express

golang

grunt

gulp

HTML

Icon Design

Javascript

jest

jquery

kubernetes

lambda

mobx

MongoDB

MySQL

nextjs

nginx

nodejs

objective-c

oclif

qwik

react

react-native

redux

responsive design

ruby

SASS

serverless

swift

SwiftUI

symphony

Typescript

webpack

yarn

StempelUhr App

Website.png

Shop-Fair / technische Umsetzung

Bildschirmfoto 2022-01-14 um 16.55.59.png

Intermittent Fasting

tzdesign.de.png

Freibad Grasleben

Bildschirmfoto 2022-01-15 um 09.07.20.png

EAGOSH

Bildschirmfoto 2022-01-14 um 17.00.50.png

Tobias Zimmermann

software architect and interaction designer

Letzte Blogeinträge

Meine Projekte

Software und Skills