Factory 2.1 Coming Soon

[hmlongco]

Features

Factory 2.1 has a set of exciting new features that include...

• Contexts allow quick and easy Factory customization when doing previews, debugging and testing.
• Provides once modifier which allows one-time initialization on a per-Factory basis.
• Let's you define the default scope used for a given container.
• Allows you to specify promised optionals that warn when registrations are not provided.
• Singletons now span containers and are cached separately.
• Factory library now implemented across multiple files.

Let's peek at one of the new features:

Contexts

Once reason Factory 2.0 leaned heavily into the modifier syntax is that I knew this feature was coming. Now I'm happy to announce it!

Developers often use Factory to mock data for previews and unit tests. Now Factory 2.1 extends these capabilities by allowing them to easily specify dependencies based on the application's current context.

What if, for example, you never want your application's analytics library to be called when running unit tests?

Piece of cake. Just register a new factory closure for that service whenever it runs in that particular context.

container.analytics
      .onTest { StubAnalyticsEngine() }

Factory provides a variety of contexts for testing, debugging, previews, simulator, device, and for checking passed parameters when running UI tests and checking builds on services like BrowserStack.

As an example of the later:

myServiceType
    .onArg("mock0") { EmptyService() }
    .onArg("mock1") { MockServiceN(1) }
    .onArg("error") { MockError(404) }

Now you can have a single build change its behavior based on passed parameters.

Develop

I've currently putting some of the finishing touches on the documentation, but Factory 2.1 is currently available in the develop branch if you want to check it out.

[doozMen]

I'm building a design system. For the brands we build it of we inject various tokens. The simplest token is a color, but it can essentially be any type. Besides a brand which is set at module initialisation, and then registers the correct factories we also have a sub theme approach which colors a subview to different colors, like light/dark, but then for a small part of the screen.

My question is if I could use the context approach for this?

But let me clarify with an exampele

struct HelloWorldView: View {
@Intjected(\.textColor) private var textColor: Color

  var body: some View {
    Text("Hello World")
       .foregroundColor(textColor)
  }
}

Now I would like to instantiate 2 instances of HelloWorld to display in a stack but with different colors based on the context I instantiate them?

struct ContentView: View {
  var body: some View {
      VStack {
           HelloWorldView()
                   .context("foo")
          HelloWorldView()
                  .context("bar")
      }
  }
}

In the above the context is a ViewModifier which should be written but I struggle with using Factory 2.0.

• What would be your approach? Or do you recommend not to use Factory for this behaviour
• Would the context thing that you are introducing into 2.1, which I really like btw, be something that could be used to build the conceptual viewModifier of my example?

[doozMen]

don't worry I use Factory also to inject a theme manager now. I was just wondering about the individual colors and if this would be a good idea.

[doozMen]

The sponsorship is a combined thanks as I used Resolver in many projects and now Factory, which I like more. So no worries.

[doozMen]

I do have a question. What do you mean with heavy? Performance or effort?

The Container with individual color factories would be in my case generated code as the basis for it is in token studio and figma (json lets say). So it is no effort to write elaborate registrations.

[doozMen]

Last if performance wise it is no effort I now think that the 2.1 feature with context is not the best approach possible. Rather injecting a container looks more like the way to go.

So this is a bit off topic for this discussion sorry.

I wrote a small unit test to verify my assumption

func testFactoryContainers() {
    let containerDefault = Container()
    containerDefault.themeableColor.register { .purple }
    let containerSport = Container()
    containerSport.themeableColor.register { .blue }

    struct View {
      private let container: Container
      var color: SwiftUI.Color { container.themeableColor() }

      init(container: Container) {
        self.container = container
      }
    }

    XCTAssertEqual(View(container: containerDefault).color, .purple)
    XCTAssertEqual(View(container: containerSport).color, .blue)
  }

This works perfect and solves my goal. But do you think performance wise this would be an issue?

[hmlongco]

Heavy in regard to performance. Keep in mind that SwiftUI views are constantly being created and diffed in response to changes in state.

[doozMen]

I have a question related to the context a of a factory. Now the context is switched global. But as I was reading the docs I expected the context to be something you set on a container instance, not on a factory and global.

The idea is that you could build in hierarchy in your dependency chain. A bit like in SwiftUI how the environment works for example with ColorScheme.

If you in SwiftUI apply .environment(\.colorScheme, .light) to a subview the colorScheme of the subview and all of its subviews change, not the parent views.

If you only can change the context of a factory instead of the context of a container it is not possible to apply local changes when using the technique in your docs of passing a container instance rather then using the Container.shared instance.

Do you think it would be possible to add a context at the level of a Container?

[doozMen]

ContainerManager.reset(options:) looks like an option that could be used for this if it would allow to just set a new context?

[hmlongco]

Contexts are global. The entire app is running in debug more or it's not. It was passed a "mock0" argument at runtime or it wasn't. The onArg and onDebug and other context modifiers basically define how the app should respond to that particular context.

[doozMen]

Could clarify what the FactoryContext.setArg("arg", forKey: "key") key in this case means. Is it just used to be able to remove the argument later on?

This looks ideal for feature flags!

[hmlongco]

There was an example in the contexts doc.

Runtime Arguments

You can also add and remove your own arguments at runtime. Consider this...

FactoryContext.setArg("light", forKey: "theme")
FactoryContext.removeArg(forKey: "theme")

myStyleSystem { StandardTheme() }
    .onArg("light") { LightTheme() }
    .onArg("dark") { DarkTheme() }