Merge pull request #104 from StuClift/add-language-identifiers

Improve readability of code blocks in docs

Author: hmlongco

Documentation/Annotation.md

@@ -8,7 +8,7 @@ This is commonly done on Android using Dagger 2, and we can now do something sim
 
 Resolver now supports resolving properties using the new property wrapper syntax in Swift 5.1.
 
-```
+```swift
 class BasicInjectedViewController: UIViewController {
     @Injected var service: XYZService
 }
@@ -24,7 +24,7 @@ The Injected property wrapper will automatically instantiate objects using the c
 ###  Lazy Injection
 
 Resolver also has a LazyInjected property wrapper. Unlike using Injected, lazily injected services are not resolved until the code attempts to access the wrapped service.
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @LazyInjected var service: XYZNameService
     func load() {
@@ -37,7 +37,7 @@ Note that LazyInjected is a mutating property wrapper. As such it can only be us
 ###  Weak Lazy Injection
 
 Resolver also has a WeakLazyInjected property wrapper. Like LazyInjected, services are not resolved until the code attempts to access the wrapped service.
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @WeakLazyInjected var service: XYZNameService
     func load() {
@@ -51,13 +51,13 @@ Note that LazyInjected is a mutating property wrapper. As such it can only be us
 
 You can use named service resolution using the `name`  property wrapper initializer as shown below.
 
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @Injected(name: "fred") var service: XYZNameService
 }
 ```
 You can also update the name in code and 'on the fly' using @LazyInjected.
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @LazyInjected var service: XYZNameService
     var which: Bool
@@ -72,7 +72,7 @@ If you go this route just make sure you specify the name *before* accessing the
 ###  Optional injection
 
 An annotation is available that supports optional resolving. If the service is not registered, then the value will be nil, otherwise it will be not nil:
-```
+```swift
 class InjectedViewController: UIViewController {
     @OptionalInjected var service: XYZService?
     func load() {
@@ -84,7 +84,7 @@ class InjectedViewController: UIViewController {
 ### Injection With Protocols
 
 Injecting a protocol works with all of the injection property wrappers.
-```
+```swift
 protocol Loader {
     func load()
 }
@@ -102,19 +102,19 @@ Registration of the class providing the protocol instance is performed exactly t
 
 You can specify and resolve custom containers using Injected. Just define your custom container...
 
-```
+```swift
 extension Resolver {
     static var custom = Resolver()
 }
 ```
 And specify it as part of the Injected property wrapper initializer.
-```
+```swift
 class ContainerInjectedViewController: UIViewController {
     @Injected(container: .custom) var service: XYZNameService
 }
 ```
 As with named injection, with LazyInjected you can also dynamically specifiy the desired container.
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @LazyInjected var service: XYZNameService
     var which: Bool

Documentation/Arguments.md

@@ -116,7 +116,7 @@ Why? Because property wrappers are at heart properties and they're immediately i
 It can't, for example, do `@Injected(args: self.editMode) var viewModel: XYZViewModel` as `self` isn't available. Swift won't allow it.
 
 That said, it's possible to be sneaky about it and pass arguments using `@LazyInjected`.
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     @LazyInjected var service: XYZNameService
     var editMode: Bool
@@ -160,7 +160,7 @@ To put that into English, it means the dependency-injection system creates and c
 Data is never injected.
 
 If an object requires data or values created or manipulated during runtime I'd do something like the following....
-```
+```swift
 class DummyViewModel {
     func load(id: Int, editing: Bool) { }
 }

Documentation/Containers.md

@@ -10,7 +10,7 @@ In Resolver, a resolver instance contains its registration code, its resolution
 
 Inspect Resolver's code and you'll see the following.
 
-```
+```swift
 public final class Resolver {
     public static let main: Resolver = Resolver()
     public static var root: Resolver = main
@@ -23,7 +23,7 @@ Resolver creates a *main* container that it uses as its default container for al
 
 This basically means that when you do....
 
-```
+```swift
 extension Resolver: ResolverRegistering {
     static func registerAllServices() {
         register { XYZNetworkService(session: resolve()) }
@@ -34,7 +34,7 @@ extension Resolver: ResolverRegistering {
 
 You're effectively doing...
 
-```
+```swift
 extension Resolver: ResolverRegistering {
     static func registerAllServices() {
         main.register { XYZNetworkService(session: root.resolve()) }
@@ -45,7 +45,7 @@ extension Resolver: ResolverRegistering {
 
 The static (class) register and resolve functions simply pass the buck to main and root, respectively.
 
-```
+```swift
 public static func register<Service>(_ type: Service.Type = Service.self, name: Resolver.Name? = nil,
                                      factory: @escaping ResolverFactoryArgumentsN<Service>) -> ResolverOptions<Service> {
     return main.register(type, name: name, factory: factory)
@@ -60,15 +60,15 @@ public static func resolve<Service>(_ type: Service.Type = Service.self, name: S
 
 Creating your own container is simple, and similar to creating your own scope caches.
 
-```
+```swift
 extension Resolver {
     static let mock = Resolver()
 }
 ```
 
 It could then be used as follows.
 
-```
+```swift
 extension Resolver: ResolverRegistering {
     static func registerAllServices() {
         mock.register { XYZNetworkService(session: mock.resolve()) }
@@ -91,7 +91,7 @@ This implies that if root were to point to a different container, like our *mock
 
 Now consider the following:
 
-```
+```swift
 extension Resolver {
     static let mock = Resolver(parent: main)
 
@@ -117,7 +117,7 @@ If a service is **not** found in *mock*,  the *main* parent container will be se
 
 One might ask why we simply don't do the following:
 
-```
+```swift
 extension Resolver {
     static func registerAllServices() {
         register { XYZNetworkService(session: resolve()) }
@@ -138,7 +138,7 @@ But what if, for example, we want to keep both registrations and use the proper
 
 Consider the following:
 
-```
+```swift
 extension Resolver {
     #if DEBUG
     static let mock = Resolver(parent: main)
@@ -157,15 +157,15 @@ extension Resolver {
 
 And then somewhere in our code we do this before we enter a given section:
 
-```
+```swift
 #if DEBUG
 Resolver.root = Resolver.mock
 #end
 ```
 
 And then when exiting that section:
 
-```
+```swift
 #if DEBUG
 Resolver.root = Resolver.main
 #end

Documentation/Injection.md

@@ -23,7 +23,7 @@ The first injection technique is to define a interface for the injection, and in
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     lazy var fetcher: XYZFetching = getFetcher()
@@ -38,7 +38,7 @@ class XYZViewModel {
 
 #### The Dependency Injection Code
 
-```
+```swift
 extension XYZViewModel: Resolving {
     func getFetcher() -> XYZFetching { return resolver.resolve() }
     func getService() -> XYZService { return resolver.resolve() }
@@ -70,7 +70,7 @@ Property Injection exposes its dependencies as properties, and it's up to the De
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     var fetcher: XYZFetching!
@@ -85,7 +85,7 @@ class XYZViewModel {
 
 #### The Dependency Injection Code
 
-```
+```swift
 func setupMyRegistrations {
     register { XYZViewModel() }
         .resolveProperties { (resolver, model) in
@@ -120,7 +120,7 @@ A Constructor is the Java term for a Swift Initializer, but the idea is the same
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     private var fetcher: XYZFetching
@@ -141,7 +141,7 @@ class XYZViewModel {
 
 #### The Dependency Injection Code
 
-```
+```swift
 func setupMyRegistrations {
     register { XYZViewModel(fetcher: resolve(), service: resolve()) }
     register { XYZFetcher() as XYZFetching }
@@ -170,7 +170,7 @@ Method Injection is pretty much what it says, injecting the object needed into a
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     func load(fetcher: XYZFetching, service: XYZFetching) -> Data {
@@ -207,7 +207,7 @@ Technically, Service Locator is its own Design Pattern, distinct from Dependency
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     var fetcher: XYZFetching = Resolver.resolve()
@@ -222,7 +222,7 @@ class XYZViewModel {
 
 #### The Dependency Injection Code
 
-```
+```swift
 func setupMyRegistrations {
     register { XYZFetcher() as XYZFetching }
     register { XYZService() }
@@ -246,7 +246,7 @@ Annotation uses comments or other metadata to indication that dependency injecti
 
 #### The Class
 
-```
+```swift
 class XYZViewModel {
 
     @Injected var fetcher: XYZFetching
@@ -261,7 +261,7 @@ class XYZViewModel {
 
 #### The Dependency Injection Code
 
-```
+```swift
 func setupMyRegistrations {
     register { XYZFetcher() as XYZFetching }
     register { XYZService() }

Documentation/Installation.md

@@ -4,7 +4,7 @@
 
 Resolver is available through Swift Package Manager. To install it simply include it in your package dependencies:
 
-```
+```swift
 dependencies: [
     .package(url: "https://github.com/hmlongco/Resolver.git", from: "1.1.2"),
 ]
@@ -16,7 +16,7 @@ Or in Xcode via File > Swift Packages > Add Package Dependency...
 
 Resolver is available through CocoaPods. To install it, simply add the following line to your Podfile:
 
-```
+```swift
 pod "Resolver"
 ```
 

Documentation/Names.md

@@ -121,7 +121,7 @@ Now the view controller gets the proper view model for the job. The `lazy var` e
 
 If you're using Resolver's property wrappers for injection, you can also do the same with `@LazyInjected`.
 
-```
+```swift
 class NamedInjectedViewController: UIViewController {
     var editMode: Bool // set, perhaps, by calling segue
     @LazyInjected var viewModel: XYZViewModelProtocol

Documentation/Optionals.md

@@ -58,7 +58,7 @@ var abc: ABCServicing? = Resolver.resolve(ABCService.self)
 ##  Optional annotation
 
 An annotation is available that supports optional resolving. If the service is not registered, then the value will be nil, otherwise it will be not nil:
-```
+```swift
 class InjectedViewController: UIViewController {
     @OptionalInjected var service: XYZService?
     func load() {

Documentation/Registration.md

@@ -27,7 +27,7 @@ Let's start by adding the master injection file for the entire application.
 
 Add a file named `AppDelegate+Injection.swift` to your project and add the following code:
 
-```
+```swift
 import Resolver
 
 extension Resolver: ResolverRegistering {
@@ -53,7 +53,7 @@ Let's say you have a group in your project folder named "NetworkServices", and y
 
 Go to the NetworkServices folder and add a swift file named: `NetworkServices+Injection.swift`, then add the following to that file...
 
-```
+```swift
 #import Resolver
 
 extension Resolver {
@@ -67,7 +67,7 @@ extension Resolver {
 
 Now, go back to your  `AppDelegate+Injection.swift` file and add a reference to `registerMyNetworkServices`.
 
-```
+```swift
 extension Resolver: ResolverRegistering {
     public static func registerAllServices() {
         registerMyNetworkServices()
@@ -83,7 +83,7 @@ Now, housekeeping completed, return to  `NetworkServices+Injection.swift` and ad
 
 Just as an example:
 
-```
+```swift
 import Resolver
 
 extension Resolver {

Documentation/Scopes.md

@@ -97,7 +97,7 @@ If you don't want this behavior, and if every request should get its own `unique
 
 This scope stores a *weak* reference to the resolved instance.
 
-```
+```swift
 register { MyViewModel() }
     .scope(.shared)
 ```