feat: add support for standalone mode (default in development)

[amcgee]

This is a pretty powerful feature that was impressively easy to implement in the platform 👍

This does three things:

1. Adds a "server" input to the login dialog, which is hidden if a "static" DHIS2_BASE_URL is provided. This makes it very easy to switch between "test" servers in development mode using yarn start 🙌. The specified server URL is saved to localStorage, so it's also stickly.
2. Adds a "standalone" mode, configurable in d2.config.js or with the --standalone flag, which preserves this behavior in the production built artifact. This allows, for example, netlify deployments to also switch between backends (if desired).
3. If not in "standalone" mode, automatically sets PUBLIC_URL to . in production builds, and DHIS2_BASE_URL to ../../.., or just .. if the app is configured as a coreApp with the new d2.config.js setting.

One goal of this change is to remove the need to specify an environment variable at all in most cases - you either use the "standalone" version in development or you use the standard, automatic ..[/../..] provided for you in production. The env var can still be used to override these settings, but shouldn't be necessary except in crazy edge cases.

Two improvements for the future:

1. We should show friendly error messages when logins fail (either because of a bad server or bad auth). This currently would require a new, pure-REST login endpoint (right now the login.action we use to set the cookie always redirects to another page and the fetch errors out.
2. The logout behavior is a bit clunky right now - when you're logged into the server specified in localStorage, the app will startup logged in. You then have to logout before being able to select another server (probably ok) but this is a bit clunky because the logout link redirects to the server in question.

[netlify]

Deploy preview for dhis2-app-platform ready!

Built with commit 27d38a0

https://deploy-preview-70--dhis2-app-platform.netlify.com

[ismay]

Nice! Very nice to have.

Adds a "server" input to the login dialog, which is hidden if a "static" DHIS2_BASE_URL is provided.

I was thinking of filling this field with the DHIS2_BASE_URL if it exists, but still allowing the user to override it. Just so that you can still override it if you want to, seems nice.

[varl]

Adds a "server" input to the login dialog, which is hidden if a "static" DHIS2_BASE_URL is provided.

I was thinking of filling this field with the DHIS2_BASE_URL if it exists, but still allowing the user to override it. Just so that you can still override it if you want to, seems nice.

As long as it is hidden in production this is an OK option too.

[amcgee]

Thanks for the feedback @ismay @varl!

I like the idea of keeping the "configurability" in dev mode by defaulting to the DHIS2_BASE_URL var, but I think the utility might be limited (unless we get rid of the "sticky" localStorage piece). It also feels a bit like "hard-coding" the default? Implementing that would require adding a new "internal" env var like DHIS2_STANDALONE to effect the dev/prod switch.

I do worry that anyone who has already set DHIS2_BASE_URL in, say, a .env file will miss out on this feature in development, but hopefully the community is still small enough that we can spread the word.

I think we should promote the following workflow: no environment variables should be necessary for simple apps, though they should be allowed for configuration of the production bundle in rare cases. As such, I think I'd prefer not supporting DHIS2_BASE_URL defaults in development.

@ismay does that make sense to you? How much utility would setting the default have for you?

[amcgee]

Going to go ahead and merge this as-is, we can update later if desired.

[dhis2-bot]

🎉 This PR is included in version 1.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[ismay]

Sorry for the late reply, I was focusing on the Select and missed the notification.

I like the idea of keeping the "configurability" in dev mode by defaulting to the DHIS2_BASE_URL var, but I think the utility might be limited (unless we get rid of the "sticky" localStorage piece). It also feels a bit like "hard-coding" the default? Implementing that would require adding a new "internal" env var like DHIS2_STANDALONE to effect the dev/prod switch.

I think we probably have different workflows in mind. The way I was envisioning it you'd always retain the ability to point it to a different backend. With the base_url being a way to supply a default.

So if I understand correctly, you're aiming to have the standalone flag allow for entering a url if base_url isn't set, and if base_url is set to hide the input and point to that server, right? With the ultimate goal being to not use base_url at all.

My suggestion was mostly for convenience, so it's not critical. The way I envisioned it, it would allow for us to deploy an app to netlify, point it to, say the debug backend by default, but still allow devs to point it at another backend if they want to.

One thing I'm wondering while typing this, if we're intending to not set a default base url, does that also mean that you're not intending to ever expose the choose a server input for apps shipped with core? (Since we're then not able to set a default and it doesn't seem nice to ask users of those apps to know and enter the backend url.)

[amcgee]

@ismay no worries!

Yeah, that's the idea. Basically, there are 3 situations where this comes into play:

1. When developing locally the developer gets the option to point at any running server, so there's not much utility in having a default there.
2. When deploying on netlify (with --standalone) in some cases it might be nice to set a default, but I think this is a minor convenience feature (people can use the netlify or other SaaS deploy against their own servers). Right now the server is cached in localStorage, so it's auto-filled when the same user returns to the app. We could add a memory of "recent" servers at some point if we want. See the netlify-hosted data query playground.
3. When built in production (not with the --standalone flag) the app will be deployed to a particular instance, so the baseUrl will NOT be configurable at all and the input will be hidden. At this time the platform will automatically set the correct relative baseUrl (.. or ../../.., depending on whether or not it's a core app). As you mentioned, we can't expect the user to enter a URL when using the app on their own instance. In almost all cases the login dialog is never shown, currently, because the javascript files are also auth-gated. That may change when we start handling session expiration. See the version of Data Query Playground that's packaged as an app on the DHIS2 appstore and can be installed to a local instance

[ismay]

I see, yeah that makes sense. Thanks for explaining!