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

HTML

responsive design

SASS

amplify console

apollo-client

Javascript

jquery

MySQL

react

Typescript

Icon Design

lambda

nextjs

swift

apache

apollo-server

aws-lambda

aws-rds

MongoDB

nodejs

react-native

serverless

SwiftUI

yarn

amplify-cli

express

grunt

gulp

jest

nginx

objective-c

oclif

redux

enzyme

qwik

symphony

webpack

canvas

docker

mobx

ruby

golang

kubernetes

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