Expected Behaviour
Storm objects should be generated using Codable. This will allow us to use Swift object models to define the payload we're expecting, remove code that reduces type-safety, and allow errors to be easily surfaced when generating views at runtime.
Current Behaviour
Storm objects are generated with manual parsing / initialisation, removing type-safety and making issues harder to find.
Possible Solution
(only to be undertaken when test coverage is sufficient)
Steps to Reproduce (for bugs)
Context
As part of the codable-refactor project, parts of the codebase (mainly storm object related) will be migrated from using manual JSON parsing / initialisation to using Codable. This will allow for increased type-safety, a reduction in boilerplate code, and the ability to easily surface errors when bundles are invalid.
Expected Behaviour
Storm objects should be generated using Codable. This will allow us to use Swift object models to define the payload we're expecting, remove code that reduces type-safety, and allow errors to be easily surfaced when generating views at runtime.
Current Behaviour
Storm objects are generated with manual parsing / initialisation, removing type-safety and making issues harder to find.
Possible Solution
(only to be undertaken when test coverage is sufficient)
Steps to Reproduce (for bugs)
Context
As part of the codable-refactor project, parts of the codebase (mainly storm object related) will be migrated from using manual JSON parsing / initialisation to using Codable. This will allow for increased type-safety, a reduction in boilerplate code, and the ability to easily surface errors when bundles are invalid.