Modules and hooks in Swift

How do modules (plugins) work?

Would not be cool for those who may create objects that would work collectively with out figuring out about one another? Think about that you’re constructing a dynamic type. Based mostly on some inside situations, the fields are going to be composed utilizing the info coming from the enabled modules.

For instance you’ve module A, B, C, the place A is offering you Area 1, 2, 3, the B module is taking good care of Area 4, 5 and C is the supplier of Area 6. Now for those who flip off B, it is best to solely be capable of see discipline 1, 2, 3 and 6. If the whole lot is turned on it is best to see all of the fields from 1 to six.

We will apply this very same sample to many issues. Simply take into consideration one of many largest plugin ecosystem. WordPress is utilizing hooks to increase the core functionalities by way of them. It is all based mostly on the idea I simply talked about above. That is a part of the event-driven structure design sample. Now the query is how can we implement one thing comparable utilizing Swift? 🤔

A hook system implementation

First we begin with a protocol with some extent of invocation. This technique can be known as by the module supervisor to invoke the correct hook perform by title. We’ll cross round a dictionary of parameters, so our hooks can have arguments. We’re utilizing the Any sort right here as a worth, so you’ll be able to ship something as a parameter underneath a given key.

protocol Module {
    func invoke(title: String, params: [String: Any]) -> Any?
}

extension Module {
    func invoke(title: String, params: [String: Any]) -> Any? { nil }
}

Now let’s implement our modules utilizing a simplified model based mostly on the shape instance. 🤓

class A: Module {

    func invoke(title: String, params: [String: Any]) -> Any? {
        swap title {
        case "example_form":
            return self.exampleFormHook()
        default:
            return nil
        }
    }

    non-public func exampleFormHook() -> [String] {
        ["Field 1", "Field 2", "Field 3"]
    }
}

class B: Module {
    func invoke(title: String, params: [String: Any]) -> Any? {
        swap title {
        case "example_form":
            return self.exampleFormHook()
        default:
            return nil
        }
    }

    non-public func exampleFormHook() -> [String] {
        ["Field 4", "Field 5"]
    }
}

class C: Module {
    func invoke(title: String, params: [String: Any]) -> Any? {
        swap title {
        case "example_form":
            return self.exampleFormHook()
        default:
            return nil
        }
    }

    non-public func exampleFormHook() -> [String] {
        ["Field 6"]
    }
}

Subsequent we’d like a module supervisor that may be initialized with an array of modules. This supervisor can be liable for calling the correct invocation technique on each single module and it will deal with the returned response in a type-safe method. We’ll implement two invoke technique variations straight away. One for merging the consequence and the opposite to return the primary results of a hook.

You may attempt to implement a model that may merge Bool values utilizing the && operator

Right here is our module supervisor implementation with the 2 generic strategies:

struct ModuleManager {

    let  modules: [Module]
    
    func invokeAllHooks<T>(_ title: String, sort: T.Sort, params: [String: Any] = [:]) -> [T] {
        let consequence = self.modules.map { module in
            module.invoke(title: title, params: params)
        }
        return consequence.compactMap { $0 as? [T] }.flatMap { $0 }
    }

    func invokeHook<T>(_ title: String, sort: T.Sort, params: [String: Any] = [:]) -> T? {
        for module in self.modules {
            let consequence = module.invoke(title: title, params: params)
            if consequence != nil {
                return consequence as? T
            }
        }
        return nil
    }
}

You should use the the invokeAllHooks technique to merge collectively an array of a generic sort. That is the one which we are able to use to collect all he type fields utilizing the underlying hook strategies.

let manager1 = ModuleManager(modules: [A(), B(), C()])
let form1 = manager1.invokeAllHooks("example_form", sort: String.self)
print(form1) 

let manager2 = ModuleManager(modules: [A(), C()])
let form2 = manager2.invokeAllHooks("example_form", sort: String.self)
print(form2) 

Utilizing the invokeHook technique you’ll be able to obtain the same conduct just like the chain of duty design sample. The responder chain works very comparable comparable, Apple makes use of responders on virtually each platform to deal with UI occasions. Let me present you the way it works by updating module B. 🐝

class B: Module {
    func invoke(title: String, params: [String: Any]) -> Any? {
        swap title {
        case "example_form":
            return self.exampleFormHook()
        case "example_responder":
            return self.exampleResponderHook()
        default:
            return nil
        }
    }

    non-public func exampleFormHook() -> [String] {
        ["Field 4", "Field 5"]
    }
    
    non-public func exampleResponderHook() -> String {
        "Hi there, that is module B."
    }
}

If we set off the brand new example_responder hook with the invokeHook technique on each managers we’ll see that the result is kind of completely different.

if let worth = manager1.invokeHook("example_responder", sort: String.self) {
    print(worth) 
}

if let worth = manager2.invokeHook("example_responder", sort: String.self) {
    print(worth) 
}

Within the first case, since we’ve an implementation in one in all our modules for this hook, the return worth can be current, so we are able to print it. Within the second case there isn’t a module to deal with the occasion, so the block contained in the situation will not be executed. Informed ya’, it is like a responder chain. 😜

Conclusion

Utilizing modules or plugins is a robust strategy to decouple some components of the code. I actually love hook capabilities since they will present extension factors for nearly something within the utility.

Combine this with a dynamic module loader and you’ve got a fully-extensible next-gen backend answer on high of Vapor. You may have a compiled core system independently from the modules and in a while you’ll be able to improve just a few components of the whole stuff with out touching the others. Whops… I simply made that occur and I believe (similar to Swift) it completely rulez. 🤘🏻

I am working laborious each on my upcoming Sensible server facet Swift e book and the open-source weblog engine that is powering this website for fairly some time now. I used this modular structure lots throughout the creation of my engine. Cannot wait to launch the whole lot and present it to you. 😉