Als je TrueFoundry hebt gebruikt om een service te pitchen, een cluster aan te maken, een LLM-model te configureren of secrets te beheren, heb je gewerkt met formulieren die eruitzien als een normale UI, maar die heel anders zijn gebouwd dan typische webformulieren.

Waarom TrueFoundry schema-driven forms gebruikt

TrueFoundry-formulieren vertegenwoordigen vaak manifests - YAML/JSON-objecten die je ook kunt toepassen met de CLI (tfy apply -f ...). Hetzelfde object kan worden bewerkt in de UI, gedownload als YAML, of ingediend bij de API.

Een schema-driven aanpak geeft TrueFoundry:

• Één bron van waarheid voor formulierstructuur (geladen vanuit de backend per brontype).
• Consistent gedrag voor deployments, clusters, policies, models, secrets, instellingenformulieren of elk ander formulier in het platform.
• Geneste en voorwaardelijke velden zonder de formulierlogica op elk scherm opnieuw te schrijven.
• Domeinspecifieke widgets (cluster picker, secret selector, resource limits) aangesloten op een gedeelde runtime.

Het mentale model: het schema beschrijft de vorm van de gegevens en hoe deze moeten worden bewerkt; FormBuilder zet die beschrijving om in een werkend formulier.

1. Formulierschema:

Een formulierschema is een array van velddefinities. Elk veld is een object met een paar belangrijke eigenschappen:

Hier is een vereenvoudigd generiek voorbeeld - geen echt TrueFoundry-schema, maar dicht bij hoe het product over configuratie denkt:

Resulterend manifest/configuratie bij indienen:

2. Hoe componenten worden gekoppeld en velden worden gerenderd

Rendering gebeurt in een kleine pipeline, de stroom is:

FormBuilder doorloopt de schemaboom en kiest per node een React-component op basis van uiType.

Componenttypen:

• Basis: Input, Select, Radio, Switch, Number
• Structureel: Group (sectie), Structs (herhaalbare lijst), KV / ENV (sleutel-waarde)
• Domeinspecifiek: ClusterSelect, SecretSelect, Resources, ModelSelect, PermissionsMatrix, MCP-velden, en meer

Voorwaarden: Als image.type !== "existing", wordt het URI-veld nooit gemount. Met shouldUnregister: true verlaat het ook de formulierstatus, zodat verborgen waarden niet in de payload terecht kunnen komen.

Koppelingslogica in code:

3. Hoe de formulierstatus wordt afgehandeld

FormBuilder gebruikt react-hook-form als status-engine. Die keuze is belangrijk voor hoe het product zich gedraagt.

Initialisatie/Componentgebruik - aanmaken & bewerken:

Formulierinstelling:

Veldregistratie - elke invoer bindt aan zijn pad:

Extra context - specifieke formulieren geven runtime-gegevens door, gescheiden van veldwaarden:

Enkel object, geneste paden:

Alle veldwaarden bevinden zich in één formulierobject. Elk veld registreert zich onder zijn volledige jsonKey-pad:

• name → string op hoogste niveau
• image.type → geneste waarde
• ports.0.container_port → eerste item in een array

Wanneer je een veld bewerkt, verander je dit gedeelde object. Bij het indienen leest FormBuilder het gehele object en geeft het door aan de handler van het formulier (die meestal de TrueFoundry API aanroept of YAML genereert).

Standaardwaarden en bewerkingsmodus:

Bij het openen van een formulier om iets aan te maken, kunnen defaultValues leeg zijn of uit een template komen.

Bij het bewerken is defaultValues typisch het bestaande manifest. De formulieren vullen zich vooraf vanuit dat object. Sommige velden zijn gemarkeerd als onveranderlijk in de bewerkingsmodus (bijv. resourcenaam) zodat ze alleen-lezen worden gerenderd.

Verborgen velden worden verwijderd uit de status:

TrueFoundry-formulieren gebruiken shouldUnregister: true. Dat betekent:

• Als een veld verborgen is door een voorwaarde, wordt de registratie in de formulierstatus ongedaan gemaakt
• De waarde lekt niet uit naar de ingediende payload

Dit is belangrijk voor voorwaardelijke formulieren: je dient alleen in wat de gebruiker daadwerkelijk kon zien en bewerken.

4. Hoe validatie werkt

Validatie in TrueFoundry-formulieren vindt plaats op twee lagen.

Laag 1: Schemavalidatie (declaratief)

Het validate-blok van elk veld kan het volgende specificeren:

• required
• min / max (toegestaan bereik van geheel getal)
• minLength / maxLength (lengte van string of array)
• pattern (regex) met aangepast bericht
• defaultValue
• immutable (alleen-lezen in bewerkingsmodus)

Deze regels worden omgezet in react-hook-form-validatieregels. Fouten worden inline naast het veld getoond. Validatie wordt uitgevoerd bij wijziging (mode: 'onChange'), zodat gebruikers feedback krijgen terwijl ze typen, niet alleen bij het indienen.

Laag 2: Aangepaste en asynchrone validatie

Schema's kunnen ook een aangepaste validate-functie koppelen, die vaak wordt gebruikt voor:

• Uniciteit van namen (“Er bestaat al een entiteit met deze naam”)
• API-gebaseerde controles vóór indienen
• Regels over meerdere velden binnen een aangepaste component
• Schermen koppelen deze bij runtime met helpers zoals “koppel validatie aan veldnaam”. De UI toont een spinner terwijl asynchrone validatie wordt uitgevoerd (bijv. debounced naamcontrole).

Alles samenbrengen: wat je ervaart als gebruiker

Wanneer je “Create Cluster”, “Deploy Service”, “Add Model” of “Manage Secrets” opent:

• TrueFoundry laadt (of bouwt) een schema voor die resource
• FormBuilder rendert elke schemanode als de gewenste invoercomponent
• Je bewerkingen werken één enkel genest formulierobject bij
• Validatie wordt continu uitgevoerd en opnieuw bij het indienen
• Het uiteindelijke object is een manifest - dezelfde vorm die je zou gebruiken in YAML of de CLI

Dat is waarom TrueFoundry zeer complexe configuratie-UI's kan ondersteunen zonder dat elk scherm een eenmalig formulier is: de complexiteit zit in het schema en een bibliotheek van veldcomponenten, georkestreerd door één gedeelde runtime.