This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-27
Channels
- # bangalore-clj (1)
- # beginners (187)
- # braveandtrue (52)
- # calva (7)
- # cider (17)
- # cljs-dev (14)
- # clojure (27)
- # clojure-austin (4)
- # clojure-dev (11)
- # clojure-finland (4)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spec (9)
- # clojure-uk (27)
- # clojurescript (91)
- # datomic (40)
- # duct (4)
- # emacs (14)
- # figwheel-main (36)
- # fulcro (11)
- # hoplon (10)
- # immutant (9)
- # instaparse (4)
- # java (1)
- # jobs (2)
- # off-topic (28)
- # pedestal (1)
- # reagent (15)
- # reitit (7)
- # remote-jobs (6)
- # ring-swagger (3)
- # shadow-cljs (28)
- # slack-help (1)
- # spacemacs (4)
- # specter (1)
- # sql (3)
- # testing (3)
- # tools-deps (24)
@dottedmag а что ты потом с этой внешней мапой делаешь? трансформируешь в кложурную внутреннюю? если да, то сразу трансформируй (set/rename-keys или че там), и потом по внутренней православной спеке проверяй. проверять спекой не так дешево, что ты прям сэкономил бы трансформацию, если бы внешней спекой чекнул сначала
еще вариант walk/keywordize-keys
сначала, а потом у же (s/keys :req-un ...)
, потом трансформация, потом (s/keys :req ...)
Может это тоже подойдёт? https://github.com/funcool/struct
@kirill.salykin Спасибо за ссылку. Я только на днях думал начать пилить нечто подобное.
есть еще spec-tools - https://github.com/metosin/spec-tools
@kirill.salykin Спасибо.
"Since struct is a young project there may be some API breakage." [funcool/struct "1.3.0"]
эээ?
@misha Мне надо оба слоя валидировать: первый на границе системы, чтобы не принимать лажу, второй внутри, чтобы проверять инварианты.
Непринятие лажи по жёстким критериям важно, так как система чем-то похожа на блокчейн: несколько узлов принимают ченджсеты и строят из них идентичное состояние.
@dottedmag а схема-то подошла?
@dottedmag пример спеки-то подошел?
ИМХО, после спеки - схему уже как-то не хочется, но для некоторых случаев это пока самый адекватрый вариант. Мы сейчас пытаемся жить и с тем и с другим ввиду специфичности стека. В итоге как устроено у нас: Все query в нашу api мы проверяем схемой, там все просто, схемы хватает за глаза и она работает из коробки в нашем веб-сервере. А вот все, что приходит в body (post put) уже более интересные вещи, там могут быть довольно сложные валидаторы, которые в схеме фиг опишешь без костылей и тут приходит на помощь спека. Так вот, для таких запросов у нас цепочка интерцепторов в которыой слачала корексятся body, а потом накладывается спека для валидации. Коерсить можно хоть spec-tools хоть spec-coerce, это уже на любителя. Втрая либа сильно проще и занимается исключительно коекцией.
@misha Это был модельный пример для того, чтобы выявить неадекватность спеки для задачи.
Вариант с :external/*
интересный, но в нём всё равно нужно ручками коэрсию делать дальше.
Самое простое! Легко дописывается чего не хватает. https://github.com/wilkerlucio/spec-coerce