Привет. Вопрос по Decodable Представьте struct A: Decodable, в котором 25

свойств, из них 24 штуки String и декодируются из коробки. А одно Bool, которое в JSON приходит в кавычках “false” и не декодируется. Как выйти из положения не переписывая целую простыню декодирований для всех 24 стрингов?
Может как-то можно переопределить decodeIfPresent для Bool? (У меня не получилось)

Не понял ответ)

это String «false»

проста матчинг сделай == чему

Где его сделать-то? Надо чтобы Decodable декодировался автоматом. Как обработать строку в бул я-то разберусь))

добавь Decodable get variable типо var boolVal { return «true» == valueFrom } кажется примерно так пишется

Понял, вычисляемое свойство. Это да, но хотелось прямо по красоте без лишнего)

if let value = try values.decodeIfPresent(String.self, forKey: .boolValue) { self.boolValue = «true» == valueFrom } else { self.boolValue = false} тогда так))

Та это я понимаю, но это надо писать в init, а тогда надо все остальные 24 свойства просто так тоже руками декодировать. Вопрос именно как избежать ручной обработки всех остальных свойств.

и это можно

Что это и как? Не понял)

может отдельный тип с инитом из singleValueContainer сделать и у него boolValue?

Если кому интересно, на стэковерфлоу мне классный варик предложили https://stackoverflow.com/questions/65981840/how-to-decode-single-unusual-property-among-many-decodable-swift/65982070#65982070

Спасибо :), мне со вчера интересно было....ранее (издревле) тру-вэй был, что есть «объект для сети», и объект для приложения который инициализируются «обьектом для сети» и в этом инициализаторе все преобразования и конвертации время в строки и тд, опять же позволит тестировать «json из сети» если ошибка в нём. Второй вариант более простой, реализовать init(from: decoder) и писать все 24 свойства, это в принципе норм, так как потом ещё какое-то поле тип поменяет, мало ли, или конвертация какая-то. Но так сразу не соображу чем вариант плох (если не нашёл минусов...значит они найдутся позже, в неподходящий момент :) ) И вот сейчас третий вариант с пропертиРапперами: и возможно со временем все 24 свойства будут обёрнуты в «попробуй как-нибудь распарить», вроде удобно, но опять же, надо подумать не о плюсах а возможных минусах

Конкретно в моем случае, не парсятся не сами свойства конкретные, а 2 типа, Bool и Date (куча свойств на этих 2 типах). При этом Decodable моделей, которые вложены друг в друга, в общем свойств огромное кол-во. Это ответ Apple на запрос верификации рецепта AppStore. И как раз тут проще 2 врапера простых написать, чем увеличивать код моделей в 3 раза (не забываем enum), причем в разных моделях один и тот же Bool и Date. Короче будет месиво нечитаемое если писать вручную все init))

Понятно, у тебя выход из ситуации :) я скорее концептуально стал думать: а если, в будущих приложениях, с самого начала сделать все свойства вот так «обёрнутыми», типа как ДакТайпинг в процессе парсинга )). Как это повлияет...

Ну если бы были все свойства такими, то через init проще)

Да, более явно....наверное «обертки» в данном случае всё-таки чтобы выручить в какой-то момент.