Repost from Linear: One thing here is that you dont need to plug the service account key in the model JSON 🙂

Other than that, demo looks great! thanks for the fast addition.

@claude Please review this code for clarity and maintainability. One component that I feel is at-risk is "AddDataForm.svelte", so please include an inspection of that code.

Claude finished @ericpgreen2's task —— View job

Code Review for PR #8142: Explicit credentials for GCS

I've completed a thorough review of this PR, focusing especially on AddDataForm.svelte as requested. Here's my detailed analysis:

🔍 Overall Assessment

This PR successfully implements explicit credential support for GCS with a step-based form flow. The implementation is functionally sound but has significant maintainability concerns in AddDataForm.svelte that need attention.

⚠️ Major Concerns with AddDataForm.svelte

1. Component Complexity (High Priority)

web-common/src/features/sources/modal/AddDataForm.svelte:1-986

Issues:

• 986 lines in a single component - far exceeds maintainable size
• Multiple responsibilities: form validation, state management, UI rendering, YAML generation, file handling
• Deep conditional nesting makes logic flow difficult to follow
• Reactive statement overuse creates hard-to-debug dependencies

Specific Problem Areas:

// Lines 77-96: Complex reactive logic mixing step state and form updates
$: if (
  isMultiStepConnector &&
  stepState.step === "source" &&
  stepState.connectorConfig
) {
  // 20+ lines of form manipulation logic
}

// Lines 347-378: Massive yamlPreview reactive statement
$: yamlPreview = (() => {
  // 30+ lines of complex conditional logic
})();

2. State Management Complexity

AddDataForm.svelte:63-100

Issues:

• 7 different form states (paramsForm, dsnForm, clickhouseParamsForm, etc.)
• Multiple reactive variables that depend on each other creating circular dependency risks
• Step state management mixed with form state creates coupling

3. Duplicated Form Logic

AddDataForm.svelte:550-866

Issues:

• Form field rendering logic is repeated 4+ times with slight variations
• Error handling patterns duplicated across different form types
• Validation logic scattered throughout the component

✅ Positive Aspects

1. Clean Supporting Files

• connectorStepStore.ts is well-designed with clear separation of concerns
• Radio.svelte is properly structured with good prop interfaces
• constants.ts provides good type safety and configuration management

2. Security Implementation

runtime/drivers/gcs/gcs.go:109-135

• Proper credential validation in Go backend
• Secure handling of both credential types (JSON credentials vs HMAC)
• Good error handling for authentication failures

3. Type Safety

The TypeScript interfaces and types are well-defined, providing good compile-time safety.

🛠️ Specific Recommendations

Immediate Actions (High Priority)

1. Break down AddDataForm.svelte:

   AddDataForm.svelte (coordinator, <200 lines)
   ├── FormRenderer.svelte (field rendering logic)
   ├── GCSMultiStepForm.svelte (GCS-specific flow)
   ├── ClickHouseForm.svelte (already exists, good!)
   ├── FormValidation.ts (validation logic)
   └── YamlPreview.svelte (preview generation)
   

2. Extract Common Form Logic:

   // useFormManager.ts
   export function useFormManager(connector, formType) {
     // Centralize form state management
   }
   
   // FormRenderer.svelte
   export function renderFields(properties, form, errors) {
     // Centralize field rendering
   }

3. Simplify Reactive Statements:

   $: formConfig = computeFormConfig(stepState, connector, formType);
   $: validationState = computeValidation(formConfig, formValues);

Medium Priority Improvements

4. Create Step Management Hook:

   // useStepManager.ts  
   export function useStepManager(connector, isMultiStep) {
     // Centralize step transitions and state
   }

5. Standardize Error Handling:

   // errorUtils.ts
   export function handleFormError(error, formType) {
     // Centralize error processing
   }

Code Quality Issues

6. Lines 195-224: The isSubmitDisabled reactive statement is too complex
7. Lines 406-479: handleOnUpdate function is doing too much
8. Lines 678-815: GCS multi-step form logic should be extracted

🧪 Testing Coverage

The test file shows good coverage of the new functionality, testing both authentication methods and step transitions.

📋 Action Items Summary

Must Fix:

• Split AddDataForm.svelte into smaller, focused components
• Extract common form logic into reusable utilities
• Simplify reactive statement dependencies

Should Fix:

• Create dedicated step management utilities
• Standardize error handling patterns
• Add JSDoc comments for complex functions

Nice to Have:

• Add storybook stories for new components
• Create form field registry pattern
• Add performance monitoring for form operations

🎯 Bottom Line

While this PR delivers the required functionality successfully, AddDataForm.svelte has grown into a maintenance liability. The component should be refactored into smaller, focused components before adding more features. The supporting files and backend implementation are well-crafted.

Recommendation: Consider this PR functionally approved but plan immediate refactoring work to address the maintainability debt.

1. Break down AddDataForm.svelte:

   AddDataForm.svelte (coordinator, <200 lines)
   ├── FormRenderer.svelte (field rendering logic)
   ├── GCSMultiStepForm.svelte (GCS-specific flow)
   ├── ClickHouseForm.svelte (already exists, good!)
   ├── FormValidation.ts (validation logic)
   └── YamlPreview.svelte (preview generation)
   

These are acceptable codesmell as we plan on tackling this in https://linear.app/rilldata/issue/APP-449/composable-adddataform We covered this in our 1:1

These are acceptable codesmell as we plan on tackling this in https://linear.app/rilldata/issue/APP-449/composable-adddataform We covered this in our 1:1

This PR introduces significant complexity with the multi-step form logic. It expands the AddDataForm.svelte component from 689 lines to 990 lines, which is over-the-line. At this point, let's try to make this component incrementally smaller in every PR, not larger. At the very least, this PR should factor out the multi-step form logic.

These are acceptable codesmell as we plan on tackling this in https://linear.app/rilldata/issue/APP-449/composable-adddataform We covered this in our 1:1

This PR introduces significant complexity with the multi-step form logic. It expands the AddDataForm.svelte component from 689 lines to 990 lines, which is over-the-line. At this point, let's try to make this component incrementally smaller in every PR, not larger. At the very least, this PR should factor out the multi-step form logic.

I've broken down AddDataForm.svelte into modular components and w.r.t https://linear.app/rilldata/issue/APP-449/composable-adddataform. Tested the connectors manually and they look good to me!

PRD review: fixed the issues reported in Linear, (gs text checker, public buckets via skip.).

Looks good! 💯

No need to fix in this PR, but if I type something in HMAC, hit skip and hit back the text is still there. also, click out of HMAC should clear the HMAC so it clears from Connector Preview.