2025-04-16 development notes

2025-04-16 19:51:58 +02:00 · 2025-04-16 19:51:58 +02:00 · f408bc51bf
commit f408bc51bf
parent aea5d27f20
1 changed files with 75 additions and 0 deletions
--- a/meeting-notes/2025-04-16_development-notes.md
+++ b/meeting-notes/2025-04-16_development-notes.md
@ -0,0 +1,75 @@
+Attendees: @kiara @fricklerhandwerk
+
+- adapted semantics of JSON schema conversion to the module system: https://git.clan.lol/clan/clan-core/pulls/3335
+- fixed some build issues in https://git.fediversity.eu/Fediversity/Fediversity/pulls/307
+- got form rendering to work again in https://git.fediversity.eu/Fediversity/Fediversity/pulls/285
+  - also minor cleanups on the way to getting it mergeable
+- discussed considerations of mapping NixOS modules to UI elements
+  - problem: NixOS modules don't have a notion of field label (important for forms) and the best we can currently do is derive it from the attribute name (meh)
+  - related work by @hsjobeki:
+    - https://discourse.nixos.org/t/zurich-24-11-zhf-hackathon-report/59250#p-197228-on-user-interfaces-for-nixos-configurations-6
+    - https://github.com/NixOS/nixpkgs/pull/341199
+  - @fricklerhandwerk: not convinced that adding more hard-coded fields to module options is the right way
+    - it's ad hoc, where does it end?
+    - the problem statement is relevant though, we need to somehow annotate presentation aspects
+  - @kiara: https://rjsf-team.github.io/react-jsonschema-form/ implements these annotations
+    - @fricklerhandwerk: textual references are a maintenance burden; opportunity for human error
+- sketched an idea for structural annotations using a module system wrapper:
+
+```nix
+let
+  fancy-wrapper = go-wild (
+    { lib, ... }:
+    let
+      inherit (lib) mkOption types;
+    in
+    {
+      options = {
+        initialUser = mkOption {
+          type = types.submodule {
+            options = {
+            displayName = mkOption {
+                type = types.str;
+                description = "Display name of the user";
+                meta.ui = lib.mkOptionMeta {
+                  type = types.uiSchema;
+                  value = {
+                    title = "Display name";
+                  };
+                };
+            };
+      };
+    });
+in
+{
+  module-options = fancy-wrapper.module;
+  annotations = fancy-wrapper.annotations;
+}
+```
+
+The `fancy-wrapper` would inject a custom `lib` where module-system-related functions will essentially act as `id` to preserve the information passed to them. On its outputs it will
+- reconstruct the module specification, throwing away the `meta` annotations
+- splice out the `meta` annotations and convert them to regular modules with the appropriate fields
+
+Then, the value of `fancy-wrapper.annotations` would mirror the stuctrue of the module in the example be equivalent to something along the lines of:
+
+```nix
+{ lib, ... }
+let
+  inherit (lib) mkOption types;
+in
+{
+  options = {
+    initialUser = {
+      displayName = mkOption {
+        type = types.uiSchema;
+        default = {
+          label = "Display name";
+        };
+      };
+    };
+  };
+}
+```
+
+Matching up the string identifiers could then be done programmatically by a function (supplied with the fancy wrapper library for use within the Nix language), so humans would be out of the loop.