This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (45)
- # beginners (44)
- # calva (3)
- # cider (14)
- # clara (4)
- # clj-commons (3)
- # clj-otel (4)
- # cljsjs (1)
- # cljsrn (111)
- # clojars (5)
- # clojure (62)
- # clojure-europe (14)
- # clojure-nl (2)
- # clojure-uk (4)
- # clojurescript (31)
- # community-development (16)
- # conjure (7)
- # cursive (9)
- # data-science (1)
- # datalevin (10)
- # docker (1)
- # emacs (20)
- # fulcro (7)
- # helix (10)
- # jobs (4)
- # lsp (22)
- # malli (35)
- # meander (12)
- # music (1)
- # nbb (2)
- # off-topic (5)
- # pathom (3)
- # quil (1)
- # re-frame (12)
- # react (6)
- # reagent (18)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (4)
- # ring (1)
- # shadow-cljs (10)
- # spacemacs (9)
- # tools-build (17)
@valtteri moving discussion of malli here, regarding json schema, the first item we should tackle, and hardest, IMO, is time schemas. There was a PR I opened and a long thread on it in the issues. It seems like the biggest tension there is good-enough vs. specification compliance How do you want to handle it?
for cljs I would vote for https://github.com/henryw374/cljc.java-time (what tick uses) but how do you deal with this now being a dependency of malli?
I think the java.time stuff looks good and in CLJS we could perhaps just use js dates (I know, they’re bad) or goog.date?
We can always make initial release under
malli.experimental.something so we can move on and get feedback
how about a code path branch using dynaload? - one set of schemas backed by js dates and one by js-joda (cljc.java-time)
And if it’s a decision between “good enough” and “specification compliance” this one leans to “good enough”
Would these be realistic goals? • good and practical defaults for Java • “good enough” defaults for JS • no new deps With a quick glance Ben’s suggestion for the java impl looks good and practical to me. I’ll promise to read through all the linked references tonight.
Thanks I'd also try getting feedback from Henry, both on our current options and maybe on a path forwards, how we could reach full spec compliance while delivering something that covers 99% of use cases in the meanwhile
I think we anyway want to have extension points so that the behaviour can be customized.
With an eye towards an end goal of using json schema or async api across an organization, with a variety of languages, I want to at least have parity in features
Unsure if this is in the scope of your discussion, but I'm currently working on an effort that uses the support Malli has for this so far, and besides a lack of built-in support for types beyond
date-time, the other pain point I've been running into for time types is that the generated JSON schemas are less restrictive than the Malli schemas they're based on. A
uuid? in Malli becomes a value with a string with a
date-time in JSON – but JSON Schema validators are not required to treat
formats as normative. This means another system could consume the JSON Schema output to validate a message, pass the message to the system using Malli, and then have it rejected as invalid. My workaround has been manually adding a
I've been thinking this and one way to circumvent the date/time type problem could be to treat them as strings. There could be a regex schema according to the
format in JSON-schema. Dunno if this would make any sense though. But this is how it works in JSON-schema.
I've read through all the earlier conversations and checked a couple of different JSON schema implementations how they do it. I think I'm more confused now than in the beginning. 😄
Yeah. But what do you think @UK0810AQ2 if in JSON-schema temporal types are strings with some enforced format.. would it make sense to do it in the same way on malli side?
Another thing we should clarify is that which version(s) of the JSON-schema spec are we targeting to support
We can also try to not solve the malli temporal schemas in general but make json-schema specific variants. If this would help us to move on
Thing is, in malli you can accept strings and make sure they transform to timestamps. When they leave the system they'll be serialized back to strings anyway
Yeah I understand that but I was thinking since timestamps are the “blocker” because there are so many possible ways to do them and it's difficult to make it good for both java and js, we could try to avoid those decisions. Java side is more clear to me. We could also think “java first and js some day”.
If we think only Java and assume your suggestion about the types, there are no blockers…right? :thinking_face:
I think we could whip up a working example to make it concrete. I guess the types can easily be changed if better suggestions pop up