iOS - improve decoding logic

[theffc]

Problems

1- We have some duplicated code for handling Actions and Components, they both share the same patterns like: how users define new types; how to associate and store a name for a specific type; how to decode the name of the type and provide the decoded object. If we were able to generalize this, we would decrease duplicated code and would be ready to accept new types like those in the future

2- Today we have 4 core types: RawAction, RawComponent, Action, and Component. This could be a little difficult and weird for our users since they effectively wouldn't want to use just a RawComponent that can't be rendered. But the problem itself is that when users create a custom widget that can receive actions or components inside it on the JSON, they will need to use RawAction and RawComponent.

3- This is a really complex problem, and we don't really know how and what we want to do with it
Today we are really coupled with the Decodable "framework" of iOS. Some pain points emerge from that:

• Decodable makes somewhat difficult to users when defining custom components

Solutions

1- generalize decoding logic to work in the same way for Actions, Components, and other abstractions that might come

• refactor AnyDecodableContainer.init(from:)
• refactor some methods of ComponentDecoder which could be grouped

2- Raw: We can make Action and Component the default way of using these abstractions for users, another good thing of this is that we would facilitate when we totally remove Raw* . For this we would need to:

• provide all the methods that we have inside KeyedDecodingContainer to work as well with Action and Component
• change our sourcery template to provide these implementations as well when user is using types without Raw prefix

3- research if it would be good and viable to use another way of decoding (without using Decodable), and if that would improve our API

• see if using some new features of dynamic things (to interface swift to work with more dynamic languages) would make this possible, and maybe try to use JSONObject
• we shouldn't waste to much time here because the solution would probably affect many parts of our project, and would be difficult to do

Important notes

• about automatic synthesized conformance with Decodable: it's not possible to have that with a property that is a protocol. E.g: a component that has another component of type RawComponent or Component. This is a limitation of Swift and it's actually difficult to describe it.

• Why don't we use Class instead of Structs and Protocols in this architecture that uses Decodable?

  • This question appears frequently, and we sometimes forget the reasoning behind it. The answer is that by using inheritance (Classes) we would solve the problem of not having to declare variables again, but we would still have the problem of Initializers and Decodable: when subclassing, we (and our users) need to manually call super for init and decoder. That way, just changing Structs to Class would not be efficient to solve our problems, if we would use Classes, we would still need a way to generate all this boilerplate code.