Readonly inputs for primitives properties in Widgets for Angular
Tags: angular, components, widgets, javascript
Published: 2017-08-27 17:41:34

---
title: Readonly inputs for primitives properties in Widgets for Angular
published: true
description: Another way to handle the inputs in a widget in a right way.
tags: angular, components, widgets, javascript
---

Hi! It's me again. Today I'm releasing the first stable version of my Pomodoro application. I made it using Angular 4, and Electron. While I was developing it, I try to use TDD, use a ngrx/Store, and separate the components of [the Widgets](https://dev.to/michaeljota/widgets-and-components-for-angular-2-and-up), and use [the @Input-set, and template-get](https://dev.to/michaeljota/input-set-pattern-for-widgets-in-angular) for manage data. 

But I have to say it, I failed, I failed big time. First at all, I come to realize why TDD is a design pattern, if you don't have defined what you want to do, you can't test first. I try to use the Store, but at the end I managed all the state from one component. But I did use Widgets to display the content, where I could. Well, this is actually the first application I do by my self, so, don't be mean. I've been working with AngularJS since 1.2, and with Angular since RC5, but I never had to design the functionality of the app, the business logic was a piece of the company I'd worked on. 

However, where I failed the most was at using the @Input-set/template-get duo. I mean, I could use them, but I most manage primitives values, so why bother? Still, one advantage of this approach is that you could treat the values as inmutables, because you set it somewhere, and return it somewhere else, there is no place to side effects there. 

So how to deal with primitives, without written unnecessary code lines, and still maintaining the immutability? Well, Typescript 2 brought a nice feature to deal with this `readonly modifier`. You can read more about that [here](https://basarat.gitbooks.io/typescript/docs/types/readonly.html). It is different from a const, cause the assignment check it's doing in compilation time, instead of runtime. Meaning, that even if you set your property to `readonly`, in runtime in can be written as many times as needed. But this approach allows us to be sure that the property will be only written by the inputed value, and we ain't going to modify it.

```typescript
export enum Cicle {
  // Cicle values
}

@Component({
  // Component definitions
})
export class StartButtonWidget {
  @Input()
  public readonly cicle: Cicle;
  @Output()
  public onClick: EventEmitter<Cicle> = new EventEmitter<Cicle>();

  public get label(): string {
    // Returns a strings from the value of the cicle
  }

  public emit(): void {
    this.onClick.emit(this.cicle);
  }
}
```

As you can see, using a readonly property for our input primitives allow us to be sure about how and when it's the property changing. But, I still think this have a disadvantage. If you need to input a value, and display another value, you could accidentally access the property in a wrong way. And I don't mean you exactly, but the team you work in. With the `@input-set/template-get` the intentions you have when you write are clears, but with this, you have to be sure that the primitive is going to be use the way you expect. Documentation would be do it, I think.

This is just another way to deals with properties in Typescript and Angular framework, I'm sure that you have many ways more, and I would like to read about them in the comments bellow.

As always, thanks for reading, and I hope you'd liked.