5 ms·
Relying on hacks for production code is usually a red flag/code smell that indicates there was probably a better alternative. `string & {}` definitely feels lik
by ricardolopes 4y ago
Relying on hacks for production code is usually a red flag/code smell that indicates there was probably a better alternative. `string & {}` definitely feels like one of those hacks.
As an alternative, wouldn't it be better to map the list of supported values in a structure like an enum?
Example:
```
enum HelloWorldValue {
Hello: 'hello',
World: 'world'
}
const value = HelloWorldValue.Hello
```
And now you can call that enum when declaring a variable value and get its contents in autocomplete. As a nice bonus, because these are references and not strings, you can ask your IDE for all places instantiating those values, which can be a life saver.
- WirelessGigabit 4y agoThis is what happens when you are building rules are around an existing system versus the other way around. In another language you have a value of type String which can take any value, might crash, might not, when you give it a color value. And then you have a set of items like you described, which are convertible to String (or are a string, like your enum). In fact, the receiver property probably shouldn't even be String, but typeof Color, which can be constructed through a method/constructor that ensures the String input is a valid format. Because which color is "XXXXXX"?
- 3836293648 4y agoBased on the last time I played with thml colours, probably red
- pvinis 4y ago> This is what happens when you are building rules are around an existing system versus the other way around. exactly right!
- shortrounddev 4y agoIt's also a lot of effort for a language which seems to be incapable of runtime type checking. Typescript is a glorified linter