Hack the stack.

Spring Boot + Kotlin + GraphQL + MongoDB — Part 1

Most discussions of GraphQL focus on data fetching, but any complete data platform needs a way to modify server-side data as well.

In REST, any request might end up causing some side-effects on the server, but by convention it’s suggested that one doesn’t use GET requests to modify data. GraphQL is similar - technically any query could be implemented to cause a data write. However, it's useful to establish a convention that any operations that cause writes should be sent explicitly via a mutation.

• This post is a sequel to Spring Boot + Kotlin + GraphQL + MongoDB — Part 1.
• Demo project repository is available at GitHub.

Creating your first GraphQL mutation

In the previous post, I tried to explain how one can fetch Person object from the MongoDB using GraphQL queries. In this post we are going to insert the Person object into a database with the GraphQL mutations. Let’s go!

Update PersonDao

createPerson(name:) method is appended to PersonDao class which passes name argument to the save(S) method from PersonRepository. As PersonRepository implements CrudRepository, so we got save(S) method for free.

GraphQL input

Read about GraphQL input types.

Create person_input.graphqls file inside resources/graphql/input directory with following content:

input PersonInput {
    name: String!
}

and the associated data class named PersonInput inside graphql/input package:

GraphQL mutation

Create mutation.graphqls inside resources/graphql directory with following content:

type Mutation {
    # Creates person
    personCreate(input: PersonInput!): Person!
}

Same method must exist in GraphQLMutationResolver subclass, which is a Spring BootComponent. A good place to put it is in the graphql package:

PersonDao is our connection to a data layer. Passing a name should create a Person record in the database.

We’re done coding!

Executing mutation

Run mvn spring-boot:run and execute some mutations in the GraphiQL interface!

mutation {
  personCreate(name: "Joey Tribbiani") {
    id
    name
  }
}

should return something like:

{
  "data": {
    "personCreate": {
      "name": "Joey Tribbiani",
      "id": "b6ff8f21-923f-43a4-b84a-9e81705c8159"
    }
  }
}

Congratulations, you have successfully connected GraphQL mutations to the MongoDB!

aronbalog/SpringGraphQLExample

Hack the Stack

Spring Boot + Kotlin + GraphQL + MongoDB — Part 2: Mutations

Spring Boot

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”. Most Spring Boot applications need very little Spring configuration.

Features

• Create stand-alone Spring applications
• Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
• Provide opinionated ‘starter’ POMs to simplify your Maven configuration
• Automatically configure Spring whenever possible
• Provide production-ready features such as metrics, health checks and externalized configuration
• Absolutely no code generation and no requirement for XML configuration

Kotlin

Kotlin is statically typed programming language for modern multi-platform applications. It drastically reduce the amount of boilerplate code.

Example of POJO with getters, setters, equals(), hashCode(), toString() and copy() in a single line:

data class Customer(val name: String, val email: String, val company: String)

Example of singleton:

object ThisIsASingleton {
    val companyName: String = "JetBrains"
}

GraphQL

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data.

A GraphQL service is created by defining types and fields on those types, then providing functions for each field on each type. For example, a GraphQL service that tells us who the logged in user is (me) as well as that user's name might look something like this:

type Query {
  me: Person
}

type Person {
  id: ID
  name: String
}

Once a GraphQL service is running (typically at a URL on a web service), it can be sent GraphQL queries to validate and execute. A received query is first checked to ensure it only refers to the types and fields defined, then runs the provided functions to produce a result.

For example the query:

{
  me {
    name
  }
}

Could produce the JSON result:

{
  "me": {
    "name": "Sherlock Holmes"
  }
}

MongoDB

MongoDB is a document database with the scalability and flexibility that you want with the querying and indexing that you need.

• MongoDB stores data in flexible, JSON-like documents, meaning fields can vary from document to document and data structure can be changed over time.
• The document model maps to the objects in your application code, making data easy to work with.
• MongoDB is a distributed database at its core, so high availability, horizontal scaling, and geographic distribution are built in and easy to use.

Let’s get started!

You can find this project at GitHub.

Go to start.spring.io and create starter package with following dependencies:

• Web
• MongoDB

application.properties configuration:

spring.data.mongodb.database=example
spring.data.mongodb.port=27017

MongoDB must be installed prior running the mvn clean install command.

If everything is ok, it should build successfully:

Run mvn spring-boot:run and try to open http://localhost:8080 in web browser.

Response should look like this:

Integrating GraphQL

Add following dependencies to pom.xml file:

<dependency>
   <groupId>com.graphql-java</groupId>
   <artifactId>graphql-java</artifactId>
   <version>8.0</version>
</dependency>
<dependency>
   <groupId>com.graphql-java</groupId>
   <artifactId>graphiql-spring-boot-starter</artifactId>
   <version>4.0.0</version>
</dependency>
<dependency>
   <groupId>com.graphql-java</groupId>
   <artifactId>graphql-java-tools</artifactId>
   <version>5.0.0</version>
</dependency>
<dependency>
   <groupId>com.graphql-java</groupId>
   <artifactId>graphql-spring-boot-starter</artifactId>
   <version>4.0.0</version>
</dependency>
<dependency>
   <groupId>com.graphql-java</groupId>
   <artifactId>graphql-java-servlet</artifactId>
   <version>5.0.0</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.2.9.Final</version>
</dependency>

and run mvn clean install. This should install all needed dependencies into the project.

Create new package with name graphql and a new package query under it.

Under resources folder, create a graphql directory. In this folder we are going to create schema files.

Package & folder structure:

Our first GraphQL query

Create new Kotlin class Query under graphql package:

and create new file named query.graphqls in resources/graphql directory:

Query type is now paired with Query class. Pay attention to @Component annotation. It indicates that an annotated class is a “component”. In Spring, such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning, so no additional configuration is required.

Now, run project by executing following command in terminal:

mvn spring-boot:run

Making requests

GraphiQL

/ˈɡrafək(ə)l/

A graphical interactive in-browser GraphQL IDE.

Open GraphQL web interface — GraphiQL (http://localhost:8080/graphiql) in your browser. It should look like this:

In the editor, type a query:

query {
  version
}

and press play button to execute it. Server should respond with:

{
  "data": {
    "version": "1.0.0"
  }
}

Congratulations! You have GraphQL service up and running.

Now, we are going to create MongoDB database, and make some read & write queries to it via GraphQL.

Creating an Entity

Entity in this example is Person.

Create new package data and data class Person inside it:

@Document annotation ensures a MongoDB document from person collection is mapped to this class.

Creating a Repository

Create new package repository and PersonRepository interface inside it:

We want our repository to be able to:

• find person by its id
• find all the persons containing characters from a given string (name)

MongoRepository extends CrudRepository so we can simply build queries by naming the repository functions properly.

findById is already provided by CrudRepository so there is no need to declare this function.

Creating a DAO

Create new package dao and PersonDao class inside it:

PersonDao injects PersonRepository interface so it can perform database queries.

Connecting GraphQL with MongoDB

Create new directory type inside resources/graphql directory and create person.graphqls (GraphQL schema) file inside it:

Extend query.graphqls like this:

Create new package query inside graphql package and create PersonQueryResolver class inside it:

PersonQueryResolver injects PersonDao, which is our connection to a data layer.

Note that query names and arguments inside query.graphqls match the method names and arguments inside PersonQueryResolver class. When the application boots, it collects all the GraphQLQueryResolver subclasses and match them with appropriate queries.

At this point, GraphQL queries should be able to read data from MongoDB database.

We need to write some data to the database to be able to read it. Execute following commands in terminal:

$ mongo
$ use example
$ db.person.insertOne( { _id: "1", name: "Sherlock Holmes" } );

Switch back web browser, go to GraphiQL interface, and run some queries!

query {
  personsByName(name: "Sherlock") {
    id
    name
  }
}

should return:

{
  "data": {
    "personsByName": [
      {
        "id": "1",
        "name": "Sherlock Holmes"
      }
    ]
  }
}

Architecture graph

• Spring Boot + Kotlin + GraphQL + MongoDB — Part 2: Mutations
• aronbalog/SpringGraphQLExample

Handle Universal Links Like a Boss.

URLs are everywhere. On our screens, billboards, in the systems, in our minds. Literally everywhere. They contain valuable information needed to perform certain operations.

In iOS, Apple added the support for universal linking. This is a very cool feature but so far it required a lot of custom code being written. Some remarks to be shared:

• URLs are changeable which can raise issues with URL matching inside an app (requires an app update)
• URLs can contain some pieces of information in their paths
• URLs can be shortened and search engine friendly

Your Swift code has a high probability to be bloated if the website that has to be linked with an app has complex URL formats that are weirdly generated.

We are gonna make an DeepLinkingExample app, which is an extended PassingDataExample app. It will demonstrate how to deal with these issues using CoreNavigation framework. Let’s get started!

1. Download and prepare DeepLinkingExample project

2. Create mockable account

mockable is a simple configurable service to mock out RESTful API or SOAP web-services.

3. Create apple-app-site-association on mockable

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "YOUR_TEAM_ID.org.corenavigation.DeepLinkingExample",
                "paths": ["*"]
            }
        ]
    }
}

Replace YOUR_TEAM_ID with your Apple Dev team id.

4. Configure target capabilities

Add mockable domain to target’s Associated Domains capabilities section in the following format:

applinks:MOCKABLE_DOMAIN

Note: Domain defined in this screenshot won’t work because it does not return correct apple-app-site-association file that matches your team id. You have to configure your own domain and ensure apple-app-site-association file is available on the network.

Use case

• App has one view controller ColorViewController which can receive UIColor & has color picker which triggers navigation to the same view controller type and passes chosen color as data to the new instance.
• App can open a deep-link URL which contains hex string in its path.
• App should map hex string to UIColor and pass it to ColorViewController.
• App should open ColorViewController with appropriate color displayed in background using following URL formats:

https://DOMAIN/color/COLOR_HEX_STRING
http://DOMAIN/colour/COLOR_HEX_STRING
https://DOMAIN/color/COLOR_HEX_STRING
http://DOMAIN/colour/COLOR_HEX_STRING

Destination

It’s nothing more than a simple view controller wrapper that provides some additional features and simplifies enrichment of truncated data (the one extracted from URL).

Destination‘s resolve method is a place where parameters from URL are mapped to data destination view controller can receive. Such destinations need to be registered along with URL pattern strings. These are used in CoreNavigation’s route matching mechanism.

App delegate

Pay attention to registerRoutes() method in AppDelegate class. It says that any URL matching any of the strings in the passed array should resolve to Color destination type.

All the parameter placeholders starting with : (colon) character will be replaced with extracted data from the URL and passed to Color‘s resolove(context:) method.

Formats to define param placeholder:

:PARAMETER_NAME

or

:PARAMETER_NAME(REGEX_MATCH_PATTERN)

Accessing extracted parameters:

let parameter = context.parameters?["PARAMETER_NAME"] as? String

In this example, route patterns are hardcoded. However, they can be generated on the server side and provided to an app so it will always stay in sync with the website and its URLs.

NSUserActivity navigation extension

CoreNavigation supports navigation to URL type, so just navigate to it.

Happy coding!

aronbalog/CoreNavigation

Passing data between view controllers.

Previous posts:

• #0 present & push… For how long?
• #1 Forget about segues.

CoreNavigation extends UIKit with additional features and tools helping you handle navigation use cases in few lines of code.

In this post, I’ll walk you through CoreNavigation’s Destination type and data passing capabilities. Source code can be found on GitHub.

We are gonna make a simple app with just one view controller containing a color picker.

ColorViewController can:

• navigate to the new view controller of same type and pass UIColor instance
• receive UIColor which will be assigned to view’s backgroundColor

View controller

ChromaColorPicker is used for the demo purpose.

Make view controller able to receive data by conforming DataReceivable protocol:

DataReceivable type has it’s associated type DataType. This means a Destination type can know about its view controller’s data type which opens a possibility to pass a concrete data from an outside world.

Destination (view controller wrapper)

Destination protocol has it’s associated type ViewControllerType which is theUIViewController type. This means destination type can know about its view controller type. In this particular case, aColor destination is paired with ColorViewController.

Navigation

Detect color picker changes and navigate:

Using Destination type is optional and practically has no use in this use case but using it will give us an advantage in our next task where we’re going to extend current app with deep linking capabilities.

Happy coding!

Next post:

#3 iOS — Reinventing view controller navigation

aronbalog/CoreNavigation

#2 iOS — Reinventing view controller navigation was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forget about segues.

Previous posts:

• #0 present & push… For how long?

Few things about segues:

• Apple’s out of the box navigation solution defined in storyboard file
• hard to inspect if you have many view controllers on one storyboard
• not good enough in more complex cases

I just don’t like them. Naming is weird. API-s are weird. I also don’t like storyboards. When reviewing other developers’ code it is just impossible to see what is going on in the xml, not to mention the pain in resolving git conflicts. CoreNavigation is 100% code based and does not yet support segues. However, you can still use view controller instances initiated from storyboards.

It’s time to boost some coding skills.

View controller navigation

Many modern app architectures wrap navigation logic but developers for some reason like to couple app’s business logic with UIKit navigation APIs. Things get messy when a client makes the request for a new feature, e.g. deep linking or state restoration. More edge cases arise when users can have multiple access levels in the app and client wants some ACL mechanism implemented to warn the user, or to intercept, redirect or even disable navigation. I know this sounds like custom business logic but it can be abstracted. Abstracting common use cases requires some deeper knowledge of UIKit navigation behavior and CoreNavigation wraps these things for you.

Passing data

The most common thing we do while navigating between screens is passing data to destination view controller. Developers tend to create custom initialisers with destination data as method arguments. This is OK for small apps (2–3 screens). Bigger apps — big no-no.

Perceive this problem as building your own town.

Small app — small town. Each of its districts is your view controller. They are connected with roads — these could be your segues. People, bikes, and cars traveling between districts are the data passed to view controllers. If the town is small enough there will be no need for road signs, people will know the path so custom initialisers on view controllers are fine. This could all be defined in a single storyboard file.

More view controllers — more need for greater control

As your town gets bigger, you’ll need to provide some traffic lights to people. Roads become highways — no more segues. Traffic lights are your custom navigation logic, e.g. green light can be letting authenticated user navigating to wanted destination view controller (district).

Letting other apps open certain view controller via deep linking is just letting tourists visit your town. Your town would need an airport or road connection with an outside world. Read more about universal linking.

Sometimes you may find yourself working in multiple-teams environment (huge apps like facebook, uber, etc.) where each team is building their own towns and you are not allowed to make any roads on your own. There is another team connecting the towns with each other and outside world.

For years I have to deal with the case where view controllers have several ways of navigating:

Truncated data
Truncated data (e.g. userId string) is passed to destination view controller which is opened immediately. Destination view controller animates a spinner while fetching full data. Fetching completion triggers layout on view controller’s view.

Full data
Full data (e.g. User object) is passed to destination view controller which is opened immediately. There is no loading animation as data is already present.

Truncated data with preloading (least used)
Truncated data (e.g. userId string) is used to preload full data (e.g.User object) which is passed to destination view controller. During the data fetching loading animation is displayed on origin view controller.

Things get interesting when one view controller needs to be able to consume both data types, truncated and full. In the first case, origin view controller would have full data and in the other case would have just a reference to a full data. Questions arise:

• Should data be fetched before navigation or after?
• How to design a data model for destination view controller?
• Where to put the code for navigation?
• Where to put the code for fetching data?
• When using state restoration, should data be reloaded or restored from cache?
• How to extract and map deep link data parameters?

Whatever the answers are, the conclusion is we need some wrapper around view controllers. They cannot stand for themselves in a world of deep links, conditional navigation, state restoration, caching etc. They need support.

In the following post I am going to talk about new term — Destination.

Next posts:

• #2 Passing data between view controllers

aronbalog/CoreNavigation

#1 iOS — Reinventing view controller navigation was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

present & push… For how long?

Through my career, I dealt with dozen different ways of navigating through screens (a.k.a. view controllers). Honestly, I never felt “safe” while using Apple’s navigation APIs.

presentViewController:animated:completion:

pushViewController:animated:

Wrapping these into some reusable components helped on some occasions but only temporarily. In environments where screen navigation is frequently used functionality, reusing such components can be very unthankful and frustrating as making a breaking change may result in an exhausting refactor across the whole stack.

I expected to see some moves from Apple on this topic since “the big refactor” (release of iOS 7 and iOS 8). I couldn’t be more wrong — so obviously, nothing happened. These minimalistic APIs for navigation are good enough for the simple use cases. But we live in a world where developers are spoiled and expect at least:

• APIs for data passing between screens (view controllers)
• APIs for conditional navigation (e.g. user is not allowed to open certain parts of the app)
• easier handling of state restoration
• URL navigation (deep linking)
• caching
• navigation history handling (like browsers do)

I stepped into the maze of potential solutions and created a new one. Many of these mentioned things are wrapped and powered by simple APIs.

CoreNavigation extends UIKit with additional features and tools helping you handle navigation use cases in few lines of code.

If you have any questions, remarks or advice it would be my pleasure to discuss it with you.

In the following posts, I will try to explain how to useCoreNavigation.

Next posts:

• #1 Forget about segues.
• #2 Passing data between view controllers.
• #3 iOS — Reinventing view controller navigation

aronbalog/CoreNavigation

#0 iOS — Reinventing view controller navigation was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Basic usage of custom operators is demonstrated in Series 6. But can we use them for something else? In this post we are gonna do little experiment.

This is the pure example how to use custom operators to improve code readability.

Our goal

let label = UILabel()
    <- "Gimme some sugar." // text
    <- 2 // number of lines
    <- UIColor.black // text color
    <- NSTextAlignment.right // text alignment
    <- UIFont.preferredFont(forTextStyle: .largeTitle) // font
    <- CGRect(x: 0, y: 200, width: 200, height: 100) // frame

Expected result

How to achieve this?

1. Declare custom operator <-

infix operator <-: AdditionPrecedence

2. Declare Configurable protocol:

protocol Configurable: class {}

3. Configurable default implementation for UIView:

extension Configurable where Self: UIView {
    static func <-(left: Self, right: UIViewContentMode) -> Self {
        left.contentMode = right
        
        return left
    }
    
    static func <-(left: Self, right: CGRect) -> Self {
        left.frame = right
        
        return left
    }
}

4. Configurable default implementation for UILabel:

extension Configurable where Self: UILabel {
    static func <-(left: Self, right: String) -> Self {
        left.text = right
        
        return left
    }
    
    static func <-(left: Self, right: UIColor) -> Self {
        left.textColor = right
        
        return left
    }
    
    static func <-(left: Self, right: NSTextAlignment) -> Self {
        left.textAlignment = right
        
        return left
    }
    
    static func <-(left: Self, right: UIFont) -> Self {
        left.font = right
        
        return left
    }
    
    static func <-(left: Self, right: Int) -> Self {
        left.numberOfLines = right
        
        return left
    }
}

5. Conform UIView to Configurable:

extension UIView: Configurable {}

That’s it!

It kinda look like a new syntax, doesn’t it? :)

let label = UILabel()
    <- "Gimme some sugar." // text
    <- 2 // number of lines
    <- UIColor.black // text color
    <- NSTextAlignment.right // text alignment
    <- UIFont.preferredFont(forTextStyle: .largeTitle) // font
    <- CGRect(x: 0, y: 200, width: 200, height: 100) // frame

Series 7— Custom operators for better code readability. was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this episode we are gonna use custom operator for setting localizable strings on UI components.

Note: This is just a simple example, not a real world solution.

This episode’s goal:

let label = UILabel() <- Localization.welcomeMessage
print(label.text?) // prints "Gimme some sugar."

Let’s declare Localizable protocol responsible for providing localized string:

protocol Localizable {
    var localizedString: String? { get }
}

Our localization is enumtype. Each of its case represents a key which will be used in NSLocalizedString macro.

enum Localization: String, Localizable {
    case welcomeMessage = "Gimme some sugar."
    case warningMessage = "Too much sugar!"
}

Localization enum is RawRepresentable with String as its associated type so this knowledge can be used in our default implementation of Localizable protocol.

extension Localizable
    where Self: RawRepresentable, Self.RawValue == String
{
    var localizedString: String? {
        return NSLocalizedString(rawValue, comment: "")
    }
}

Custom operator

We’re gonna use infix operator. Custom operators are not covered in this post. Read more about custom operators.

infix operator <-: AdditionPrecedence

Protocol which will provide abstraction for any object which has text: String? property. We’ll call it TextAware:

protocol TextAware: class {
    var text: String? { get set }
}

Apply <- operator to TextAware protocol:

extension TextAware {
    static func <-(left: Self, right: Localization) -> Self {
        left.text = right.localizedString
 
        return left
    }
}

Now we can extend UI components with TextAware:

extension UILabel: TextAware {}
extension UITextField: TextAware {}

And finally we can use:

let label = UILabel() <- Localization.welcomeMessage
print(label.text?) // prints "Gimme some sugar."

let textField = UITextField() <- Localization.warningMessage
print(textField.text?) // prints "Too much sugar!"

Pretty easy, isn’t it?

Series 6— Custom operators combined with localization was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Gimme some sugar. Series 5 — Stored properties in swift extensions + sweet UIControl action handling

In one of the previous posts I demonstrated how to use Selector extension to prettify your code. In this post we are gonna make it even sweeter.

Wishful thinking (our goal):

let button = UIButton()

button.on(.touchUpInside) {
    // we want to handle button tap here
}

UIButton inherits from UIControl which owns addTarget(_:action:for:). Read more about it.

Somehow closure has to be invoked inside the selector passed in addTarget(_:action:for:) function.

Gimme some sugar and make it sweeter.

First we need our proxy target:

// MARK: Proxy target

class Target: NSObject {
    let completion: (UIControl) -> Void
    
    init(completion: @escaping (UIControl) -> Void) {
        self.completion = completion
    }
    
    @objc func action(_ sender: UIControl) {
        completion(sender)
    }
}

At the moment there is no place to store Target instances because Swift doesn’t support stored properties inside extensions. Well, this is not entirely true.

We’re gonna call Objective-C for help here. This simple class acts as low level memory storage:

// MARK: Storage

final class ObjectAssociation<T: AnyObject> {
    private let policy: objc_AssociationPolicy
    
    public init(policy: objc_AssociationPolicy = .OBJC_ASSOCIATION_RETAIN) {
        self.policy = policy
    }
    
    public subscript(index: AnyObject) -> T? {
        get {
            return objc_getAssociatedObject(index, Unmanaged.passUnretained(self).toOpaque()) as! T?
        }
        set {
            objc_setAssociatedObject(index, Unmanaged.passUnretained(self).toOpaque(), newValue, policy)
        }
    }
}

Let’s make target storage on UIControl using ObjectAssociationclass:

// MARK: Storage extension

extension UIControl {
    private static let association = ObjectAssociation<NSMutableArray>()

    var targets: [Target] {
        get {
            if UIControl.association[self] == nil {
                UIControl.association[self] = NSMutableArray()
            }
            return UIControl.association[self] as? [Target] ?? []
        }
        set {
            UIControl.association[self] = NSMutableArray(array: newValue)
        }
    }
}

Now Target objects can be stored in UIControl instance. Cool hack, isn’t it?

And finally UIControl extension:

// MARK: Syntax sugar extension

extension UIControl { 
    @discardableResult func on<T: UIControl>(_ events: UIControlEvents, _ completion: @escaping (T) -> Void) -> Self {
        let target = Target {
            if let control = $0 as? T {
                completion(control)
            }
        }

        targets.append(target)
        
        addTarget(target, action: #selector(Target.action(_:)), for: events)
        
        return self
    }
}

We are done.

Enjoy the sweetness!

let button: UIButton = ...

button
    .on(.touchUpInside) { $0
        print("Touch up inside!")
    }
    .on(.touchUpOutside) { $0
        print("Touch up outside!")
    }

P.S. Apple should have done it in the first place, right?

Gimme some sugar. was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Take a look at this code example:

let viewController = UIViewController()
 
viewController.navigationItem.leftBarButtonItem = UIBarButtonItem(...)
 
viewController.navigationItem.rightBarButtonItem = UIBarButtonItem(...)

viewController.title = "Title"

viewController.view.backgroundColor = UIColor.white

viewController.presentData(...)
...

This have tendencies to get messy and hard to read.

Sure, some logic can be moved/wrapped to new functions, you can delegate object configuration to another objects, you can even indent some of the stuff in code, but if you use some lint tool, you’re in problems.

Gimme some sugar and make it sweeter.

protocol Configurable {}

extension Configurable {
    func configure(_ block: (inout Self) -> Void) -> Self {
        var instance = self
        block(&instance)
 
        return instance
    }
}

In this very moment, this code does nothing.

But if NSObject is extended (which is the base class in Foundation) all its subclasses become configurable:

extension NSObject: Configurable {}

Sweetness is here.

let viewController = UIViewController().configure {
    $0.navigationItem.leftBarButtonItem = ...
    
    ...
}

Gimme some sugar. Series 4 — Mutating in block was originally published in Undabot on Medium, where people are continuing the conversation by highlighting and responding to this story.