Links to a specific screen of the application does not work

[blcham]

There is no way to go to a specific screen of the application using URL, as all specific addresses always redirect to the main dashboard.

Let's show it on the screen /institutions:

As in fta-fmea-ui, we use browser-router in the front-end, but in the fta-fmea-ui it works well. Note that this issue is quite old, so it was not caused by migration to Vite.

A/C:

• it works in vite development deployment
• it works in dockerization

[blcham]

@shellyear I have added "A/C" to the description of the issue

[shellyear]

@blcham It works with dockerization, in order to test that I made a docker build, and used that image in docker-compose.yml for record-manager and tested on localhost:1235.
It works on vite dev and build. What do you mean by vite development deployment ?

[blcham]

By vite development deployment I mean working when running from http://localhost:5174.

[blcham]

@shellyear I merged the initial fix, but there are still issues:

Before your fix, when entering such URL, it navigated to the dashboard page, which is a better solution than showing a white screen. If we do not solve this issue, I would rather revert this fix.

[shellyear]

@blcham link to institution "/institution/:id" works on dev, but fails on build

[shellyear]

@blcham
It makes request, to the institutions/config somehow and can't find the institutionsController in the build after refresh (err 404)

[blcham]

That means the path to config.js is wrongly set.

[shellyear]

@blcham It works with dockerization, when I set a "base" as "/record-manager/", but for dev and build it should be not explicitly set (defautl base is "/")

[blcham]

How deployment works:

• vite.config.js has base attribute which is used to prefix all references from index.html. It can be imagined as substituting ${base} variable into index.html file as the following:

...
     <script type="module" src="${base}config.js"></script>
     <script type="module" crossorigin src="${base}assets/index-DRyJxYuK.js"></script>
...

• in config.js located at same path as index.html we set up BASENAME

window.__config__ = {
  BASENAME: '/record-manager',
  ...
}

• in App.jsx we specify relative path of pages within BrowserRouter using BASENAME:

<Router history={history} basename={BASENAME}>

• application runs at localhost${PORT}/${BASENAME} that is specified at runtime -- in docker-compose environment variable (it can be set e.g., BASENAME=/my-company/my-record-manager).

The problem:

• there is no way to specify the correct ${base} attribute because:
  • we cannot have base="/" since, in some cases, we serve nginx from subpath of BASENAME (e.g. /my-company) and thus are not able to locate index.html at the address "http://localhost/index.html". This is also the case when we serve multiple applications (multiple index.html / config.js files would exist and we cannot serve them all at "/") .
  • we cannot have a relative path, i.e. base="" (same as base="./"), because it works on the same level (subpath) of URL as index.html, but if we have a more complex path, it will not work (e.g. http://localhost:1235/record-manager/records/61920918389810463 would resolve to http://localhost:1235/record-manager/records/config.js and not http://localhost:1235/record-manager/config.js where index.html is also located)

Alternative possible solutions to fix the dockerization:

• 1. we could replace ${base} with placeholder ${BASENAME} at build-time (note, we do not want to replace actual BASENAME there, just put a place-holder) and at runtime replace it with actual value (using the docker entrypoint script)
• 2. we could specify some nginx rules on how to retrieve *.js files from the server:
  • e.g., /record-manager/records/config.js would be resolved to /record-manager/config.js
  • the same goes for /record-manager/assets/*
• 3. we can include (i.e., install) vite in the docker image and run npm run prod in there with the correct ${base} parameter specified from the docker entrypoint script
• 4. we could search for vite-specific docker images

[blcham]

Currently this is not that important now, so putting back to state TODO.

[ledsoft]

This answer helped me a lot, maybe it will help you as well: https://stackoverflow.com/a/67195723/4929038