This repository has been archived by the owner on Jun 1, 2024. It is now read-only.
iOS - improve decoding logic #774
Labels
DX
Dev Experience: something that directly degrades our users (developers) experience with our product
iOS
This issue directly affects structure and logic of iOS project
technical debt
does not affect users directly, but is an internal/technical point of improvement
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
, andComponent
. This could be a little difficult and weird for our users since they effectively wouldn't want to use just aRawComponent
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 useRawAction
andRawComponent
.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:Solutions
1- generalize decoding logic to work in the same way for Actions, Components, and other abstractions that might come
2- Raw: We can make
Action
andComponent
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: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
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?
The text was updated successfully, but these errors were encountered: