4.0.1 (2022-10-26)

Bug Fixes

• NSNull case was handled for nullable selections (#92) (bde8685), closes #89

4.0.0 (2022-08-04)

Performance Improvements

• package: Add Query Builder Methods to WebSocketClient (#84) (9252d5d)

BREAKING CHANGES

• package: This commit changes how we process the failure of query-builder decoding extensions. We no longer add the parsing error to the result but instead throw the error and pass it down the publisher chain.

3.0.1 (2022-08-03)

Bug Fixes

• release: fix publishing workflow (#80) (f24f049)
• release: Fix Release Package Bump Workflow (#79) (ad0ace1)

3.0.0 (2022-08-03)

Performance Improvements

• client: SwiftGraphQL 3.0.0 (#70) (0821319)

BREAKING CHANGES

• client: This PR improves query building logic and introduces a new full-blown GraphQL client.

2.3.1 (2022-02-09)

Bug Fixes

• Make interfaces property optional in the Introspection Query (b1fad45)

2.3.0 (2021-12-30)

Features

• Support injecting the URLSession (716973b)

2.2.4 (2021-11-16)

Bug Fixes

• bump argument parser to stable version (59484a6)
• camel casing algorithm (d7db775)
• fix string formatting when there are multiple capitalised letters together (046a165)

2.2.3 (2021-11-14)

Bug Fixes

• allow using absent file path as an output (5d75fc4)

2.2.2 (2021-11-14)

Bug Fixes

• allow multiline comments (0121a6e)

2.2.1 (2021-05-17)

Bug Fixes

• cli config (c3dee58)
• introspection error (0bf985b)

2.2.0 (2021-03-09)

Features

• add headers argument to cli (0044725)

2.1.2 (2021-03-02)

Bug Fixes

• handle decoding errors in websocket (6e7cc4d)

2.1.1 (2021-02-23)

Bug Fixes

• Add explicit platform specifictation (d3f4d2e), closes #28

2.1.0 (2021-02-22)

Features

• support headers in code generation (31f6edc)

Hi there 👋🏿 ,

We've finally reached version 2.0.0! After several immensely successful beta releases of the next major SwiftGraphQL version, I think we are ready to ship. This version includes additions that profoundly change how the first version worked. To name a few, we've implemented subscriptions support, improved code-generation, built a CLI utility and more!

I hope you find this package as useful as I've seen it fun.

Before diving into all the changes, I'd like to thank @Amzd who helped me shape this library by implementing the subscription layer and adding some fantastic suggestions that make working with SwiftGraphQL more enjoyable. @Amzd thank you! ❤️

Our mission remains the same with every version - We want to build the most approachable Swift GraphQL client, that solves few things but solves them well.

Features

• We've added support for subscriptions. To make a subscription selection, use the same pattern as before and create a socket, using the listen method.
• We've added a CLI that you may use to generate the SwiftGraphQL code. You may download it using brew, mint or build it yourself using make.
• Every structure in the schema that may be selected has type alias for better XCode IDE support. If, for example, you had a User type in the database and wanted to select a name out of it, you no longer have to make a phantom-type using Selection<User, String>. Instead, you can write Selection.User. Swift should infer the return type itself.

Internal changes

I've changed the code structure so that we expose another child-library - GraphQLAST. I haven't documented it, but it should be simple to use by following function annotations and inline docs.

Breaking Changes

• When making a selection, field decoding might throw. That's why every assignment should be marked with try.
• SwiftGraphQLCodegen no longer accepts an Options structure. Instead, you should forward scalars. Additionally SwiftGraphQLCodegen no longer writes to a file. Instead, it would be best if you used swift-graphql CLI tool as an alternative to build-phase script in version 1.x.x and 2.x.y-beta.z.
• I've removed SG and SwiftGraphQL namespaces in favour of modules.

Future plans

I've started working on the documentation page. I think it's important that we promote the library more and hopefully land on some sponsors that would encourage this library's maintenance.

This is a POC beta release. I've made significant changes to the internals of the API that still need to be documented.

This release introduces new optional() function modifier for Selection that lets you convert decoders that might return null into optional decoders that might return null.

Additionally, I've made some internal naming adjustments and nullable fields now return mock value by default instead of returning null.

This beta fixes operationName bug where the request wouldn't contain operationName variable in request body.

This beta lets you send named operations. You may do that by adding an optional operationName parameter in the send method.

SG.send(query, to: "http://localhost:4000", operationName: "Query") { result in
    if let data = try? result.get() {
        print(data)
    }
}

You might want to write a selection on the entire type from the selection composer itself. This usually happens if you have a distinct identifier reused in many types.

Consider the following scenario where we have an id field in Human type. There are many cases where we only query id field from the Human that's why we create a human id selection.

let humanId = Selection<HumanID, Objects.Human> {
    HumanID.fromString(try $0.id())
}

Now, we want to reuse that same selection when query a detailed human type. To do that, we can use selection helper method that lets you make a selection on the whole TypeLock from inside the selection.

struct Human {
    let id: HumanID
    let name: String
}

let human = Selection<Human, Objects.Human> {
    Human(
        id: try $0.selection(humanId),
        name: try $0.name()
    )
}

An alternative approach would be to manually rewrite the selection inside Human again.

let human = Selection<Human, Objects.Human> {
    Human(
        id: HumanID.fromString(try $0.id()),
        name: try $0.name()
    )
}

Having distinct types for ids of different object types is particularly useful in large projects as it gives you verification that you are not using a wrong identifier for a particular type of field. At first, this might seem useless and cumbersome, but it makes your code more robust once you get used to it.