"Injecting Typhoon Itself" not quite correct

[fatuhoku]

Typhoon is the name of the framework. By saying "Typhoon can inject itself", readers end up confused: how can a DI framework inject a DI framework into code?

https://github.com/appsquickly/Typhoon/wiki/What%20can%20be%20Injected#injecting-typhoon-itself

Instead, it should be made clear that the DI framework is able to inject Typhoon ASSEMBLIES (or ComponentFactorys but I think there are plans to make that private soon).

[jasperblues]

Thanks for the comment. Will update. by the way, the only thing typhoon can really inject in this regard is the TyphoonComponentFactory. However using late binding messages from our assembly interfaces are handled, so it looks as though we have an activated assembly.

We're going no to move the handful of methods from TyphoonComponentFactory that are useful at runtime onto the TyphoonAssembly interface.

[fatuhoku]

I noticed that TypoonComponentFactory lets you set a default factory, but you cannot set a default assembly. I would like to see that be moved into assemblies (if it makes sense!)

[jasperblues]

Tell us about that? defaultFactory can be useful especially for integrating DI into a legacy app, but it's usually preferable to inject the assembly.

[fatuhoku]

Right — that's the thing. I want to integrate Typhoon into a legacy app. I thought the first thing to replace was going to be my use of singletons (probably not the best idea actually) and so I went ahead and tried.

1. I used plist integration to enable Typhoon. I list, say, MYDefaultAssembly as an initial assembly I would like loaded.

2. I also have specified UIStoryboardFile for Typhoon Storyboard support. Now all my top-level view controllers are Typhoon-aware (can access the object graph).

3. I built my app with MVVM architecture. This requires a good number of components to work in a stack. View Controllers construct and pass the next required ViewModel during navigation. I don't have time to Typhoon-ize the entire application so I want to isolate refactorings where possible and build incrementally.

4. ViewModels are constructed manually, they are not Typhoon-aware. Sometimes constructing them requires a reference to a component, say, MYAuthenticationModule that manages user data. My aim is to get rid of [MYAuthenticationModule sharedInstance] calls. I think to myself, what is the analog of this in Typhoon?

   Clearly, I write a component MYAuthenticationModule in MYDefaultAssembly, setting definition.scope = TyphoonSingleton.

5. I need a Typhoon-esque way of injecting MYAuthenticationModule DIRECTLY, as to replace a +sharedInstance call. I effectively want to obtain some default MYDefaultAssembly through a +sharedInstance.

I think it's only possible through the TyphoonComponentFactory / makeDefault right now...

[fatuhoku]

Wow. Okay.

I just realised all that writing, and all I was missing was the -defaultAssembly method.

As much of a hack as it is, I think it's worth documenting!

[jasperblues]

(facepalm) Documentation for that actually get removed during recent overhaul. Will put back.

[fatuhoku]

@jasperblues fantastic. xD

[jasperblues]

@fatuhoku Docs corrected, please review and close or comment.