feat: add AWS region selector to DynamoDB connection form

[fuleinist]

Summary

The DynamoDB plugin cannot put a region dropdown on the connection edit page by itself:

• connection-modal.connection_content only replaces the whole form for no_connection_required drivers
• slot context has no setters for host/port/region
• ConnectionParams had no region field to persist or forward to the plugin

Without a region, the plugin falls back to us-east-1 signing for generic form connections, so real AWS endpoints in other regions fail with InvalidSignatureException (see TabularisDB/tabularis-dynamodb-plugin#59).

Changes

• Add optional region to ConnectionParams (Rust + TypeScript)
• Render a searchable AWS Region select on the GENERAL tab when driver === "dynamodb" (or engine === "dynamodb")
• Auto-fill region from dynamodb.<region>.amazonaws.com host when empty
• Region list: 34 commercial AWS regions per the AWS Regions docs
• Unit tests for region parsing / list length

Test plan

• Open/edit a DynamoDB connection — GENERAL tab shows AWS Region select after Host/Port
• Enter host dynamodb.us-west-2.amazonaws.com — region auto-fills to us-west-2
• Manually pick a different region — host change does not overwrite it
• Save + Test Connection against a real AWS account in that region
• MySQL/Postgres connections — no region field shown
• vitest run src/utils/awsRegions.test.ts

Made with Cursor

Made with Cursor

[debba]

Thanks for tracking this down. This is a real problem and I want it fixed, my only doubt is about where the fix should live.

This PR puts driver === "dynamodb" and a list of 34 AWS regions inside the core app. It works, but it means every time a plugin needs one extra connection field we add another branch to NewConnectionModal and another column to ConnectionParams. I know we already did exactly that for the SQL Server Encrypt dropdown in #236, so it's a pattern I helped create, but I'd like to stop growing it.

Your analysis of why the slot can't do it today is spot on, and those three points look like the better target:

1. hasConnectionContentSlot is gated on noConnectionRequired, so the slot only renders for drivers with no form at all, and it replaces the form instead of extending it. We could either drop that gate and keep a second anchor, or add a connection-modal.extra_fields slot rendered right after host/port for any driver.
2. The slot context only carries driver, database, onDatabaseChange and connectionName. Adding the setters there is cheap.
3. Instead of a dedicated region, an opaque extra: HashMap<String, String> on ConnectionParams, persisted and forwarded to the driver untouched, so the core never needs to know what a plugin stores in it.

With those in place the region select, the region list and the auto-fill from dynamodb.<region>.amazonaws.com all live in tabularis-dynamodb-plugin, and the next plugin that needs an API key or an account id gets it for free.

It's more work than what you have here, so no hard feelings if you'd rather not take it on. But if you do feel like tackling it, it would be a really valuable piece of work: it unblocks every plugin author who needs a custom connection field, not just DynamoDB, and it's the kind of groundwork that pays off for a long time. I'd be happy to review it in steps if that helps.

Otherwise I can open a separate issue for the slot work and we figure out what to do with this PR in the meantime. Let me know which way you prefer.

[fuleinist]

Thanks — you're right that the driver-specific field in core is the wrong place for this. Closing this PR and moving to the approach you outlined.

The plugin side is already updated in tabularis-dynamodb-plugin#59: it now parses the opaque extra: HashMap<String, String> on ConnectionParams and uses extra["region"] as the per-connection signing region (precedence: explicit region param → extra["region"] → hostname-parsed region → plugin default-region setting → us-east-1). So the plugin will honour a connection-form region selector the moment the host forwards it, with no further core coupling.

What remains on the core side — happy for this to become a separate issue, as you suggested:

1. Opaque extra: HashMap<String, String> on ConnectionParams (Rust + TS), persisted and forwarded to drivers untouched
2. A connection-modal.extra_fields slot rendered after host/port for any driver (or dropping the noConnectionRequired gate on hasConnectionContentSlot), plus the setters in the slot context
3. The DynamoDB region select, the 34-region list, and the dynamodb.<region>.amazonaws.com auto-fill then live in the plugin