DEV Community

Cover image for Why reflect-metadata suc*s

Why reflect-metadata suc*s

Jakub Švehla on May 31, 2021

Modern Typescript oriented libraries start to use classes and decorators in their APIs. Everything is awesome until libraries start to use reflect-...
Collapse
 
orefalo profile image
Olivier Refalo • Edited

I landed here cause vitest doesn't support 'reflect-metadata' #$@$!@$!#%!@%.
Thank you for the details. I guess I will need another testing framework to run my type-graphql & mikrorm app

PS:I realize every day that java had reflection right.

Collapse
 
cyrfer profile image
John Grant

This is great. I think Google suggested this article to me because I've been trying to figure out why I need a class in order to generate Swagger docs for my APIs which use TS interfaces. I wish I could tap into the TS compiler with decorators on my controller FUNCTIONs as I don't see the benefit of using a CLASS other than 'thats what you need to do'.

Collapse
 
svehla profile image
Jakub Švehla

exactly! I love the minimalism of express and nodejs/javascript ecosystem... So I don't see the purpose to have classes and methods with tons of boilerplate to programme simple typed REST-API endpoints...

Collapse
 
kierano547 profile image
Kieran Osgood

Another great example that followed your approach is mobx, the had decorator syntax added and made the default years ago when they were certain it'd come into ecma and then... It never did, last November they removed it (.. Kinda) and went for a purely js approach - kinda glad Google managed to suggest this post to me as I've recently been looking into decorators for TS as the DX is great and I'd like to get some use out of them 😅

Collapse
 
svehla profile image
Jakub Švehla

thank you for a feedback :) I'm happy that you enjoy the article

Collapse
 
sein_digital profile image
Błażej Adamczyk

I think you are missing the point here. The whole idea of TypeScript and Reflect is to bring JS world closer to high level programming languages, like Java and C#.
Yeah, sure, you can do it as close to native JS as possible, but then again, why bother with TS? Your basic argument is not against reflect-metadata, but whole concept of using typescript. Yeah, you might be vendor-locking yourself, but you do so too, whenever you use any framework for development. You are locked with that framework for the rest of the project, unless you expect some major refactoring.

...which enforces you to do extra compilation to make the code work...
Well, that's basically TS.

So tell me - whoever read this comment after this article - do you want to trade code clarity to stay "pure"? Just because you can achieve same thing harder in native way, does it mean, you have to?
For me, it's just waste of time and energy.
What if you don't understand decorators, reflections and aspect programming? Don't worry, in 90% cases you don't have to.

Collapse
 
svehla profile image
Jakub Švehla

You're right in one thing... C# & Java sucks as well

I think that you absolutely miss understand the whole point of this article... i can't imagine to write out more code without typescript and I think that TS type system is the best type system ever because you can infer almonost all types from your pure javascript code and keep 100% type safeness. Imho there is only one similar good type system and its from F# compiler. i do not blame TS, i love it... but my code looks like JS and works like TS <3 its 2 in 1, win win situation

BTW reflect-metadata is not as powerfull as the type inferring system for more complicated data types like structures etc...
its reason why you have to define pointer into Photo two times in this example:

  @OneToOne(type => Photo)
  @JoinColumn()
  // here you duplicate the pointer into Photo just to have proper static types
  photo: Photo;
Enter fullscreen mode Exit fullscreen mode
Collapse
 
daolanfler profile image
Qi FANG

I was searching for why I can't use tsx (the esbuild based typescript execute) in replace of ts-node, found their doc and this article. I guess I have to stick with ts-node for now as my project relies on typedi and routing-controllers which are basically built around reflect-metada.

Collapse
 
arberqytyku profile image
arberqytyku

Hi Jakub,
This is a great article. Thank you for all the insights. I have two questions for you. Is it possible to use it without decorators and reflect-metadata. If not, do you know any alternative library that does the same job without decorators?

Thanks.

Collapse
 
juni0r profile image
Andreas Korth

Hey Jakub,

I just wanted to thank you for this article. It was a true eye opener. I was just digging myself deep into decorators and reflect-metadata. I had a weird feeling throughout that this is all wrong somehow.

I was searching for documentation on Reflect when Google fed me your article and you expressed precisely what to me was still just a hunch. I was shouting YES all the way through and ended my brief affair with Reflect instantly.

I also rediscovered yup, which I used in a project a few years back and found it matured into a polished library. I'm currently hosting a pool party with yup, Typescript and Wallaby and it's epic!

Godspeed and keep up the great writing!

Collapse
 
svehla profile image
Jakub Švehla

Haha!
I hope that there will be more people with the same mindset as you have!

Thanks for the feedback! I appreciate it a lot! 🥰 😄