ulsdevteam/ccvgd-frontend

Contemporary Chinese Village Gazetteer Data front end application

ccvgd-frontend's Issues

Public facing URIs are not linkable/resolvable

When deployed as an application in an Apache document root, the application responds and re-writes the public-facing URLs to endpoints such as /single-village-search and /multi-village-search.

but direct fetches of these endpoints result in 404s.

What is the expected server-level redirection needed to ensure that public facing URLs are directed to the js application?

Links rendered to unusable menu on small window sizes

When the interface is rendered on narrow window sizes, the links 单村庄搜索 and
多村庄搜索 are collapsed to a menu, but the menu does not respond to click events to expand for visible options.

Backend API endpoint unexpectedly references "ccvg"

Configuring a production build with the environment:

export const environment = {
  production: true,
  //backend service will run on this API ROOT, which points to the server
  API_ROOT: "//test.hostname.tld:8001/api/",
};

Constructs backend API calls such as:
http://test.hostname.tld:8001/api/ccvg/namesearch

But there is no guarantee that "ccvg" is a prefix in the deployment of the backend.

Document application webroot setting

The application expects to be deployed in the webroot, and will reference the javascript includes via an absolute path.

For example, deploying to "http://localhost/ccvgd/" will look for runtime-es2015.a1ac991fc00ebf39524f.js in "http://localhost/runtime-es2015.a1ac991fc00ebf39524f.js"

This should be configurable, or should be documented within the readme.

Apply a LICENSE to the repo

Code published online should describe in a license what the conditions are for its reuse and modification.

The license may be dictated by any dependencies which you use or package with the application.

If you are not constrained by existing dependencies, GPL and MIT licenses are good FLOSS options.

Backend endpoint should consider HTTP and HTTPS

In src/environments/environment*.ts, we have a single key for API_ROOT, with an example of an "http" endpoint. E.g.:

ccvgd-frontend/src/environments/environment.ts

Line 7 in 5e62deb

API_ROOT: 'http://ngrok.luozm.me:8395/',

This application itself should be able to be served over HTTP or HTTPS, at the end user's preference.

Because this API endpoint is called from the end user's web browser, via the application itself, this configuration would suggest that either the entire application should be placed behind a proxy, or that the backend API should be available to the end user via both HTTP and HTTPS.

If the example deployment will reference an HTTP endpoint, the example should also so how to configure an HTTPS endpoint as well.

If the example deployment references a relative path (that is, API_ROOT: "/backend-api/" or API_ROOT: "//localhost/backend/"), then the determination of HTTP or HTTPS can be left to the administrator who is installing the application.

Consider which deployment files should be ignored within git

Almost certainly files under dist/ and node_modules/ should be included in the a .gitignore so that the git repository is only tracking local source code changes. The dependencies and the packaged application should only exist in deployed packages (releases), or left to the administrator to deploy when the application is installed.

To capture the state of the the application when it has been tested with specific dependencies, you will want to include the package-lock.json file in the git repository. If specific dependency versions are non-critical, you may want to exclude the package-lock.json file via the .gitignore.

For configuration files where the administrator who is deploying the application has choices to make (such as database names, passwords, backend hostnames, ports, etc.), the git repo should provide sample files or sample values, with instructions to the administrator for changes. For example, consider src/environments/environment.prod.ts.