docs: Inject refactor

Author: gallayl

src/content/003-getting-started-with-inject.md

@@ -11,13 +11,17 @@ excerpt: Dependency injection and Inversion of control is a common practice that
 
 
 ## Injectable services
-An _injectable service_ is basically a class, decorated with the `@Injectable()` decorator. If you decorate a class, its injectable options (e.g. lifetime) and constructor argument types will be stored and the injector will be able to instantiate a new instance any time. Constructor arguments should be also _injectable services_ and they will be resolved recursively. Take a look at the following example and you'll get the idea:
+An _injectable service_ is basically a class, decorated with the `@Injectable()` decorator. If you decorate a class, its injectable options (e.g. lifetime) will be stored and the injector will be able to instantiate a new instance any time. You can also decorate properties with the `@Injected(Type)` decorator to inject them after instantiating the object. Take a look at the following example and you'll get the idea:
 
 ```ts
 const injector = new Injector()
 @Injectable()
 class Service1 {
-  constructor(public service2: Service2, public service3: Service3) {}
+  @Injected(Service2)
+  public service2!: Service2
+
+  @Injected(Service3)
+  public service2!: Service3
 }
 @Injectable()
 class Service2 {
@@ -54,7 +58,10 @@ The package defines four types of lifecycle:
  - **Singleton** injectables are hoisted to the root injector. If you request a singleton, the injector will check create the instance in it's highest parent - and also returns it from there, if already exists.
  - **Explicit** values are not really injectables - you can call `injector.setExplicitInstance(myServiceInstance)` to set up an instance manually. Just like scoped services, explicit instances will be returned from the current scope only.
 
-## Extension methods
+## ~~Extension methods~~
+
+[(We have already said goodbye to extension methods)](/008-byebye-extension-methods/)
+
 A simple injector can be easily extended by 3rd party packages with extension methods, just like the FuryStack packages. These extension methods usually provides a _shortcut_ of an instance or sets up a preconfigured explicit instance of a service. You can build clean and nice fluent API-s in that way - you can get the idea from one of the [FuryStack Injector Extensions](https://github.com/furystack/furystack/blob/develop/packages/rest-service/src/injector-extensions.ts)
 
 You find more inject-related articles [here](/tags/inject) or check out the package at NPM

src/content/008-byebye-extension-methods.md

@@ -9,11 +9,11 @@ draft: false
 excerpt: Using extension methods was fun at the beginning but I've ran into more and more problems with them
 ---
 
-### The Heritage from C#
+## The Heritage from C#
 
 It's not a big sectet that one of the main inspiration for FuryStack is the .NET (legacy and Core) stack where extension methods are quite common. The same can achieved in the JS world where everything is possible, every prototype can be hacked and it can be also type-safe.
 
-### The Problem
+## The Problem
 
 The main problem in short that extending another module is _not officially supported_ by Typescript - however the type system can be hacked like _it was_ in FuryStack and as you can see in the following example:
 
@@ -42,7 +42,7 @@ const result = await injector.isAuthorized('admin');
 
 ...well, it works but I've ran into unexpected issues with conflicting import declarations and overrides. The problems appeared random, but somewhat based on the running context (ts-node, jest, browser) and it started to block dependency upgrades...
 
-### How it works now
+## How it works now
 
 The extensions has been replaced by _helpers_, as you can see in the following example. These helpers are simple shortcuts - you should usually pass the injector (or the related manager class) to them as a parameter.
 The imports are clear, as well as the execution path and the types.

src/content/009-inject-refactor.md

@@ -0,0 +1,78 @@
+---
+layout: post
+title: A little bit of Inject refactor
+author: [gallayl]
+tags: ['inject']
+image: img/009-inject-refactor.jpg
+date: '2022-08-12T18:00:00.257Z'
+draft: false
+excerpt: Emitting decorator type data is doomed :(
+---
+
+## Why
+
+As you can see, in FuryStack I've tried to take some steps to use only standardized APIs to maintain the supportability. As I started to work with new tools and framework, I've found some bottlenecks. The first big bad was the hacky [extension method support](/008-byebye-extension-methods/) that I've introduced in the beginning of the project, but I've found an another black sheep in the heart of the Typescript ecosystem - Decorator support.
+
+In short: "[The emitDecoratorMetadata flag is intentionally not supported.](https://github.com/evanw/esbuild/issues/257#issuecomment-658053616)"
+
+## Emm ok, what now? 😕
+
+We had a feature in `Inject` that *was* build on a top of emitting type data and that was *constructor injection*. The syntax was like:
+
+```ts
+const injector = new Injector()
+@Injectable()
+class Service1 {
+  constructor(public service2: Service2, public service3: Service3) {}
+}
+@Injectable()
+class Service2 {
+  public value = 'foo'
+}
+@Injectable()
+class Service3 {
+  public value = 'bar'
+}
+
+expect(injector.getInstance(Service1).service2.value).toBe('foo')
+expect(injector.getInstance(Service1).service2.value).toBe('bar')
+```
+
+That's clear that we can't use this if we loose type data at runtime, so the idea was to pass down the constructor object at runtime - and try to maintain the simplicity of the old API.
+
+## The new `Injected()` properties ✨
+
+...so a new property-level decorator called `Injected()` was born.
+The very same behavior with the new API looks like this:
+
+```ts
+const injector = new Injector()
+@Injectable()
+class Service1 {
+  @Injected(Service2)
+  public service2!: Service2
+
+  @Injected(Service3)
+  public service2!: Service3
+}
+@Injectable()
+class Service2 {
+  public value = 'foo'
+}
+@Injectable()
+class Service3 {
+  public value = 'bar'
+}
+
+expect(injector.getInstance(Service1).service2.value).toBe('foo')
+expect(injector.getInstance(Service1).service2.value).toBe('bar')
+```
+
+### Some pros 👌
+ - The consrtuctor instance is passed down as a variable - without emitting non-standard metadata and other black magic
+ - The main behavior (lifetime, recursive resolution, etc...) remains the same
+
+### ...and a few drawbacks 😿
+ - Properties will be injected **after** constructing the instance - it means that you cannot use them in the constructor
+ - A breaking change - again...
+ - See the `!` operator? Yeah, it's a kind of "shortcut" for now...