Add actor generation form by sij411 · Pull Request #74 · fedify-dev/drfed

sij411 · 2026-09-08T15:10:36Z

Add an actor-generation form with validation and loading/error feedback.
Submit the selected instance global ID through Relay.

Closes #41

AI assistance

Used Codex (gpt-5.6-sol) to review the Relay/Formisch/Kobalte integration and make focused corrections to numeric input binding, an import suffix, a typo, and lint issues. I reviewed and retained the design and implementation decisions.

I implemented the actor-generation route with Formisch and Valibot validation, Kobalte controls, Relay global-ID mutation input, loading state, and distinct GraphQL, domain, and network error handling. Codex reviewed and explained the Relay and generated-type behavior, then made focused edits to route Kobalte numeric values into Formisch, correct a generated import suffix and typo, and resolve lint findings. I retained the design and implementation decisions. Codex ran the full repository check successfully. I will manually verify the UI before submitting the pull request. Assisted-by: Codex:gpt-5.6-sol

sij411 · 2026-09-08T15:25:27Z

Testing in progress

I pinned Seroval 1.5.4 in the web package so Solid Relay uses the same OpaqueReference implementation as Solid SSR, preventing serialization failures when entering preloaded dynamic routes. Codex diagnosed the upstream peer-version mismatch and applied the dependency and lockfile changes. I confirmed the fix in the development environment by entering the instance route and observing its GraphQL query execute normally. Codex ran mise run check, mise run build, mise run test, and an SSR request to the affected dynamic route successfully. Assisted-by: Codex:gpt-5.6-sol

sij411 · 2026-09-09T04:15:40Z

Currently, after creating actor, it stays on the actor creating page. Should i add some post actions?

dodok8 · 2026-09-09T13:21:42Z

How about add 'useNavigate'?

sij411 · 2026-09-10T11:14:19Z

@dodok8 navigate to instance detail page?

dodok8 · 2026-09-10T11:17:04Z

Yes.

dodok8 · 2026-09-11T12:46:52Z

+        const result = response.generateActors;
+        switch (result.resultType) {
+          case "CreateActorsSuccess": {
+            navigate(-1);


How about using navigate(-1), using more detatiled URL?

Sorry, do you mean explicit URL rather than navigate(-1)? If so, I have been working on navigating to instance detail page with explicit URL and popping up success toast.

Check this out: 49c3d6c

Navigate to the selected instance by slug after actor creation and refresh its cached actor list. Add a persistent Kobalte toast region with a dismissible success notification. Use the number field rawValue prop so clearing the actor count leaves the input editable. Codex generated these changes at my request. I verified that the toast worked and reported the empty-input NaN bug, which guided the subsequent input fix. The input fix has not been browser-verified. Validation: mise run check and mise run test (including the build) passed; lint reports a callback statement-count warning. Assisted-by: Codex:gpt-6-astra

2chanhaeng · 2026-09-09T03:03:57Z

+          case "%other": {
+            setErrorMessage("Unable to generate actors.");
+            return;
+          }


This branch is unnecessary because it's same with default branch.

without it, it violates lint rules. not satisfying the exhaustiveness check.

I don't think it is a good rule... The default branch can take the role of the case "%other" branch. You can turn off the rule by adding "typescript/switch-exhaustiveness-check": ["error", { "considerDefaultExhaustiveForUnions": true }], in rules of .oxlintrc.json.

Turning off that lint error won't trigger a lint error for a new union members. if we keep that intentional, then we can turn it off, remove %other branch, and only leave a generic fallback (default). we can leave a comment above. hows that sound

2chanhaeng · 2026-09-09T03:16:16Z

+          case "CreateActorsError": {
+            switch (result.type) {
+              case "InvalidSize": {
+                setErrorMessage("Enter at least one actor.");
+                return;
+              }
+              case "InstanceNotFound": {
+                setErrorMessage(
+                  "The selected instance could not be found or is no longer available.",
+                );
+                return;
+              }
+              case "TooManyActors": {
+                setErrorMessage(result.message);
+                return;
+              }
+              case "%future added value": {
+                setErrorMessage(
+                  "The server returned an unsupported actor-generation error.",
+                );
+                return;
+              }
+              default: {
+                setErrorMessage("Unable to generate actors.");
+                return;
+              }
+            }
+          }


I think it would be OK for now with following:

case "CreateActorsError": { setErrorMessage(result.message); return; }

Or,

case "CreateActorsError": { if (["InvalidSize", "InstanceNotFound", "TooManyActors"].includes(result.type)) { setErrorMessage(result.message); } else { setErrorMessage("Internal error."); } return; }

They are meant to be shown to users. I don't think sending API error message directly to users is ideal.

In fundamental, that's correct, but currently the error messages between both sides aren't that different and it seems like they'll be similar later on too. Also, the code is getting too long. If it still feels a bit off, how about something like this:

const ERROR_MESSAGES_BY_TYPE = { // [ERROR_TYPE]: ERROR_MESSAGE } // ... if (result.type in ERROR_MESSAGES_BY_TYPE) { setErrorMessage(ERROR_MESSAGES_BY_TYPE[result.type]); } else { setErrorMessage("Internal error."); }

If the logic for each branch ends up being very different later, the current code might be better.

2chanhaeng · 2026-09-13T02:11:11Z

+          case "%other": {
+            setErrorMessage("Unable to generate actors.");
+            return;
+          }


I don't think it is a good rule... The default branch can take the role of the case "%other" branch. You can turn off the rule by adding "typescript/switch-exhaustiveness-check": ["error", { "considerDefaultExhaustiveForUnions": true }], in rules of .oxlintrc.json.

2chanhaeng · 2026-09-13T02:24:34Z

+          store.get(instance)?.invalidateRecord();
+        }
+      },
+      onCompleted: (response, errors) => {


By the way, the max-statements lint warning shows on the onCompleted callback.

2chanhaeng · 2026-09-13T02:46:29Z

+          case "CreateActorsError": {
+            switch (result.type) {
+              case "InvalidSize": {
+                setErrorMessage("Enter at least one actor.");
+                return;
+              }
+              case "InstanceNotFound": {
+                setErrorMessage(
+                  "The selected instance could not be found or is no longer available.",
+                );
+                return;
+              }
+              case "TooManyActors": {
+                setErrorMessage(result.message);
+                return;
+              }
+              case "%future added value": {
+                setErrorMessage(
+                  "The server returned an unsupported actor-generation error.",
+                );
+                return;
+              }
+              default: {
+                setErrorMessage("Unable to generate actors.");
+                return;
+              }
+            }
+          }


In fundamental, that's correct, but currently the error messages between both sides aren't that different and it seems like they'll be similar later on too. Also, the code is getting too long. If it still feels a bit off, how about something like this:

const ERROR_MESSAGES_BY_TYPE = { // [ERROR_TYPE]: ERROR_MESSAGE } // ... if (result.type in ERROR_MESSAGES_BY_TYPE) { setErrorMessage(ERROR_MESSAGES_BY_TYPE[result.type]); } else { setErrorMessage("Internal error."); }

If the logic for each branch ends up being very different later, the current code might be better.

sij411 marked this pull request as draft September 8, 2026 15:11

sij411 force-pushed the feat/actor-page branch from 99fe1a6 to 68d9e61 Compare September 8, 2026 15:18

sij411 marked this pull request as ready for review September 9, 2026 05:06

dodok8 previously approved these changes Sep 9, 2026

View reviewed changes

Return to previous page after successful query response

10e51b1

sij411 dismissed dodok8’s stale review via 10e51b1 September 11, 2026 02:48

dodok8 requested changes Sep 11, 2026

View reviewed changes

2chanhaeng requested a review from dodok8 September 12, 2026 11:53

2chanhaeng reviewed Sep 12, 2026

View reviewed changes

2chanhaeng reviewed Sep 13, 2026

View reviewed changes

Uh oh!

Conversation

sij411 commented Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sij411 commented Sep 8, 2026

Uh oh!

sij411 commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dodok8 commented Sep 9, 2026

Uh oh!

sij411 commented Sep 10, 2026

Uh oh!

dodok8 commented Sep 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sij411 Sep 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sij411 commented Sep 8, 2026 •

edited

Loading

sij411 commented Sep 9, 2026 •

edited

Loading

sij411 Sep 12, 2026 •

edited

Loading