-
-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse objects conforming the Codable protocol #99
Conversation
do { | ||
_ = try PBXFileElement(reference: "ref", dictionary: dictionary) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably worth making an extension on PBXObject or Decodable which is init(jsonDictionary: [String: Any]
that handles all this boilerplate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good idea, I'll do it @yonaskolb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done @yonaskolb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I think you could also put an extension on PBXObject as well that is an init with reference
init(reference: String, jsonDictionary: [String: Any]
That would remove a bit of the boilerplate in tests and other places
Can I help you with it? |
Sure @artemnovichkov, you are welcome to help. It'll take us time to migrate all of them, but with help, we'll be faster 😛 |
Sources/xcproj/PBXTarget.swift
Outdated
self.buildRules = try container.decode([String].self, forKey: .buildRules) | ||
self.dependencies = try container.decode([String].self, forKey: .dependencies) | ||
self.name = try container.decode(String.self, forKey: .name) | ||
self.productName = try container.decode(String?.self, forKey: .productName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional properties should use ‘decodeIfPresent’
Sources/xcproj/XCVersionGroup.swift
Outdated
self.name = try container.decodeIfPresent(String.self, forKey: .name) | ||
self.sourceTree = try container.decode(PBXSourceTree.self, forKey: .sourceTree) | ||
self.versionGroupType = try container.decode(String.self, forKey: .versionGroupType) | ||
let children = try? container.decode([String].self, forKey: .children) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think lines like this can be:
self.children = try container.decodeIfPresent([String].self, forKey: .children) ?? []
I find this extension really useful when using Decodable extension KeyedDecodingContainer {
public func decode<T>(_ key: KeyedDecodingContainer.Key) throws -> T where T: Decodable {
return try decode(T.self, forKey: key)
}
public func decodeIfPresent<T>(_ key: KeyedDecodingContainer.Key) throws -> T? where T: Decodable {
return try decodeIfPresent(T.self, forKey: key)
}
} It makes the code easier to write as you don't need to specify the type again: - self.name = try container.decode(String.self, forKey: .name)
+ self.name = try container.decode(.name) It also means that support can be added by doing search and replace on the unbox functions |
It's very useful! Great idea @yonaskolb. I'll update the code to use it. |
Fix some tests that were failing because the PropertyListDecoder reads some attributes as strings instead of integers.
Update Package.swift and xcproj.podspec removing Unbox
I just noticed that this removed the BuildSettings typealias. Was there any particular reason for that? |
I came across some issues trying to parse the settings, and I removed it thinking it was related. It turned out it wasn't. Do you think we should keep it? |
It’s not strictly needed, but I think it was nice how it unified the types and purpose wherever build settings were used. The factthat it was public means people may have been using it too (as was the case of XcodeGen) |
Resolves #83
Short description 📝
Remove Unbox dependency by using the native Codable protocol.
Solution 📦
Update all the elements to conform the Codable protocol and remove the Unboxable conformance.
Implementation 👩💻👨💻
GIF