This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-26
Channels
- # announcements (5)
- # architecture (1)
- # bangalore-clj (4)
- # beginners (45)
- # boot (4)
- # cider (19)
- # clojure (56)
- # clojure-austin (1)
- # clojure-canada (1)
- # clojure-finland (1)
- # clojure-russia (67)
- # clojure-uk (2)
- # clojurescript (57)
- # clojutre (1)
- # cursive (15)
- # datomic (3)
- # emacs (2)
- # figwheel-main (71)
- # fulcro (117)
- # hoplon (33)
- # java (5)
- # off-topic (52)
- # pedestal (7)
- # remote-jobs (1)
- # shadow-cljs (134)
- # slack-help (9)
- # specter (1)
- # tools-deps (17)
- # vim (2)
@brownmoose3q привет, а будут ли новые выпуски? Клёвые видео, ты не бросай это дело 🙏
Господа, а у меня одного любой подход к спеке заканчивается "ох, никак с её помощью толком не повалидировать внешние данные"?
А то у меня какая-нибудь хреновина типа {"type": "add_something", "id": "<uuid>", "pos": 17, "entry": {"id": 4, ...}}
приезжает, и надо её разбирать.
Спекой неудобно. Спекой хорошо {:change/type :add-something :change/id #uuid "..." :change/pos 17 :change/entry {:entry/id 4 ...}}
проверять.
Во-вторых, во входящих данных разные типы значений под одинаковыми ключами (см. id
).
@akond И как, удобно последовательность спекать "в этой последовательности обязательно иметь вектор с первым элементом "type", обязательно иметь вектор с первым элементом "pos" и обязательно иметь вектор с первым элементом "entry""?
Мне нужна "антиспека": сделанная для закрытого мира, и с предположением, что всё входящее надо трансформировать.
Т.е. первая "вот здесь будут ключи, их все на этом уровне превратить в ключевые слова по этому алгоритму, другие все ключи - ошибка". Вторая (s/keys :req [:change/type :change/id :change/pos])
Можно, конечно, руками, но есть подозрение, что этот ручной труд можно автомтизировать.
В смысле, не писать баланду "проверить, что в этой мапе ключи строки, и там есть такие-то", а DSL а-ля спека, только наоборот.
Спека считает, что ключи уникально идентифицируют сущности, антиспека считает, что "id"
во входящем документе будет 17 раз в трёх разных синтаксисах.
Наверное, этого уже достаточно, чтобы 1) сначала сделать разбор внешних данных руками; 2) посмотреть на этот разбор и сделать из него библиотеку и DSL.
можно добавить в спеку условие :else
и туда все будет валиться, если я правильно понял что ты хочешь
Вот тебе паззл: покрой спекой JSON-чик выше. На первом уровне ключ "id"
— UUID, на втором — int64.
В любом случае, производители и потребители этого JSON – Swift и Go, так что проблемы языков без int64 их не волнуют.
`(s/explain (s/cat :first (s/and vector? (s/cat :k (partial = "type") :v string?)) :second (s/and vector? (s/cat :k2 (partial = "id") :v2 uuid?)) :third (s/and vector? (s/cat :k3 (partial = "pos") :v3 number?)) :entry (s/and vector? (s/cat :k4 (partial = "entry") :v4 some?)) ) {"type" "add_something", "id" (java.util.UUID/randomUUID), "pos" 17, "entry" {"id" 4}})`
Да, можно отсортировать, но таких мап у меня, допустим 50, и они вложенные. Всех сортировать?
И теперь результат хочется привести к виду "Спекой хорошо ... проверять", сколько это ещё будет кода?
вот еще забавная штука: https://github.com/stathissideris/spec-provider
@dottedmag даже если ты извратишься и опишешь то что тебе надо спекой, оно будет как минимум нечитаемое
schema гораздо лучше подходит для валидации внешних данных, но насчет коерсии я не уверен
ребята с Аттендифая вот довели идею схемы до refined types https://github.com/KitApps/schema-refined
(s/and map? (s/cat ...))
может имел ввиду?