Different app keys for Dropbox API for localhost and production server?

I'm developing a client-side-only web app that will use the Dropbox JavaScript SDK to allow users to store their work in a folder in their Dropbox (at /Apps/MyAppName). I've done this:

1. In the Dropbox App Console, I created an app and got an app key.
2. I started a test repo on my laptop and successfully implemented Dropbox auth/read/write. This required adding to the Dropbox App Console a redirect URL like http://localhost:myport/my-redirect-page.html.

Now I'd like to migrate the code from the test repo into my real project, which will be hosted at myappname.github.io. My client-side JavaScript needs the app key, so it will be visible to anyone who looks for it. As far as I understand it, I have two options:

1. Remove the localhost redirect URL from Dropbox App Console. But then I can no longer use Dropbox features when testing my own app during development.
2. Leave the Dropbox App Console settings alone. But then anyone can take my app key, try to guess the name of my redirect page, and build a Dropbox app on their machine that seems to Dropbox as if it were my app.

Google Drive solves this problem by allowing each app to generate more than one API key and assign different URLs to each one, so you can have a developer one you never share and a production one that doesn't work with localhost. Dropbox doesn't seem to have this feature, as far as I can tell; it's one app key per app.

Am I misunderstanding the situation and/or the security concerns? If not, is my only solution to make a second app just for testing? Perhaps the best answer would also mention any relevant best practices for the client-side Dropbox JavaScript SDK that my question shows I don't know.

Dropbox does not support registering separate redirect URLs for different app keys on a single app registration. Some developers use a single app registration with all of their redirect URLs set on it, while some register multiple apps (e.g., one for development and one for production).

If you have particular security concerns, I recommend consulting with a security professional.

That said, if you are worried about someone taking your app key and impersonating your app using your localhost redirect URL, then creating two separate app registrations is the right way to address that.

It's worth noting though that app keys (a.k.a. client IDs or consumer keys) are effectively public in general, as are the redirect URL(s) used by a released app. (The protection comes from the fact that someone else can't add other redirect URLs that they control to your app registration since they can't log in to your account.) As for any localhost redirect URLs themselves, any such redirect URLs are of limited use because there would need to be local access to access those in practice to begin with.