requestOperationIdExtension adds private extension making it inaccessible if in a separate file about createapi HOT 11 CLOSED

Before I noticed the flag, I asked about the purpose in kean/Get#33 and you are right, it is designed for this.

So in that case, maybe we do just pass the id through the convenience methods.. something like this:

public static func get(_ url: String, query: [(String, String?)]? = nil, headers: [String: String]? = nil, id: String? = nil) -> Request {
    Request(method: "GET", url: url, query: query, headers: headers, id: id)
}

What do you think about this @kean?

from createapi.

Yes, I recommend using the initializer because otherwise, you might end up using methods that'll get deprecated soon. The initializer won't change any time soon or ever.

from createapi.

Just taking a look at this, should we just always generate a functional helper:

public extension Request {
    public func settingID(_ id: String) -> Request { // different name, but functional in context
        var copy = self
        copy.id = id
        return copy
    }
}

from createapi.

Could it even just be a case of removing the private from the existing template?

from createapi.

Ultimately yes, but this seems so small to be behind a flag especially since the user can just edit the id variable directly. Additionally, the functional name could be a change.

from createapi.

Or, this could be a change in Get itself as it seems more appropriate there

from createapi.

Using isAddingOperationIds will fail if the schema doesn't specify an operationId for one or more of its operations, which is allowed as per the spec.

So at the moment, the flag is necessary. But that being said, I've seen other tools automatically infer the operationId from the path + method, which we could also do. And if we did, then we'd be able to just generate it automatically (or maybe just leave it as nil?)

Or, this could be a change in Get itself as it seems more appropriate there

Yeah I did think about that and it is also a possibility. It would simplify things

from createapi.

I think it would be safe to add the operationId as the Request.id by default, nil if none specified. Get does not use the id property so it's mainly for developer usage (unless I'm missing something or it has actual Request usage in somebody's package).

from createapi.

I'm still debating how to design it. I don't think I've done a great job with all these telescoping methods. There are too long, duplicated, and I keep forgetting the order of parameters.

I'm thinking about taking a cue from the SwiftUI design:

// Now
_ = Request.post(
    "/domain.tld",
    query: [("query", "value1+value2")],
    body: value,
    headers: ["a": "b"]
).withId("getDomains")

// Target state
_ = Request.post("/domain.tld", body: value)
    .query([("query", "value1+value2")])
    .headers(["a": "b"])
    .id("getDomains")

But I'm not sure it'll work well with the existing writable properties with the same names. It does work, but I'm sure there are going to be some issues because of the name clashes.

from createapi.

Right now you can use the existing initializer for code generation purposes:

    public init(
        method: String = "GET",
        url: String,
        query: [(String, String?)]? = nil,
        body: Encodable? = nil,
        headers: [String: String]? = nil,
        id: String? = nil
    ) {

It didn't have the id parameter prior to Get 1.0, but it does now.

from createapi.

Thanks for the input! Ok that makes sense, the telescoping methods (TIL) methods are more for manual usage and it doesn't really matter what the generated code uses. We can generate implementations that use Request.init(...) directly instead 👍

from createapi.