This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-28
Channels
- # aleph (7)
- # babashka (13)
- # beginners (10)
- # biff (4)
- # calva (75)
- # cljs-dev (22)
- # clojure (55)
- # clojure-berlin (1)
- # clojure-europe (15)
- # clojure-nl (1)
- # clojure-norway (35)
- # clojure-serbia (1)
- # clojure-uk (2)
- # clojurescript (46)
- # community-development (1)
- # core-async (23)
- # data-science (1)
- # datalevin (2)
- # datascript (10)
- # datomic (11)
- # fulcro (28)
- # helix (12)
- # hyperfiddle (26)
- # introduce-yourself (4)
- # malli (16)
- # off-topic (1)
- # pathom (4)
- # pedestal (1)
- # polylith (12)
- # quil (11)
- # releases (3)
- # scittle (24)
- # shadow-cljs (85)
- # specter (1)
- # sql (9)
- # xtdb (5)
I've been thinking about the malli-opts
being defined in com.app
instead of a file everything can import from. I'm guessing the idea was to have it only be accessible from ctx
, but I have found it helpful to pool all my schemas in one namespace and create a registry there, ditching the :schema
plugin key altogether. My reasoning
1. To me, there's not much point in letting every plugin define it's own schema since there's no "scoping" that comes with it. If you want your schemas in different files, you can do that and just have schema.clj
import them all.
2. If you want to do your own validation, passing down the malli-opts to your functions can get more and more annoying. And if you want to use the malli schemas in metadata, you can't get it from function arguments.
3. Doing it this way lets you use generative testing a lot more easily across your Biff app, since you can access the registry directly. If you want to use function schemas from Malli, you can write a small function to easily select biff fields. Here is a function that can take a whole character object, but requires a few keys. It's validated at runtime and can be checked with generative testing.
(defn calculate-armor
{:malli/schema [:=> [:cat (schema/get-fields :char
[:char/armor :char/shield])]
:int]}
[char]
(let [armor-key (:char/armor char)
shield-key (:char/shield char)]
(+
(armor-key {:modern 1
:bulky 1
:none 0})
(shield-key {:on 1
:off 0}))))
Biff makes it easy to reinstrument these functions when the schema changes by adding !
to the on-save
functionI too have moved malli-opts
into a lower level file. I still have :schema key in my plugins though. I use example-based testing, and in my test files I create an in-memory xtdb and a special malli registry for only the plugins tested by the test file.
(def plugins [dbuser/plugin dbparty/plugin dbwork/plugin dbentry/plugin])
(def malli-opts (dbmisc/make-malli-opts plugins))
I think I will move all the schema to a single file, as you have done.
That sounds reasonable to me. The only reason I added the :schema
key to plugins/modules was that Biff's authentication module requires https://github.com/jacobobryant/biff/blob/09ef8cef88cb699c67de124cbb472bbff0142d69/src/com/biffweb/impl/auth.clj#L262, and I wanted the process for using the module/any other 3rd party module that includes its own schema to be "just add this function to your modules list" without also requiring people to add schema to a second place in their codebase.
However for "regular" schema defined in your application code, there really isn't any benefit to going through the module system. Maybe I'll rejigger things so malli-opts
/ the schema registry is once again defined in the schema.clj
file, and then that can still get merged with any additional schema that modules define.