Monolith with React client and all other options default jhipster config UI issues related to menu and translations

[idexxt2]

Overview of the issue

Two issues:

1. Using the jhipster command to create a monolith application with all default options except selecting React as the client UI causes "translation-not-found[]" (e.g. "translation-not-found[home.question]") whenever the user changes the language selection from the generated app's menu. All text on the page which has entries in the translation config files will show these translation-not-found messages in place of the actual translations. If you refresh the browser page after changing the selected language from the app menu, then the proper text appears in the selected language.
2. After logging into the generated app, the text for "Settings" in the "Account" drop down menu still says "Sign in". The icon next to this text is a wrench (the correct icon for Settings), but the menu text is wrong. This is confusing to anyone who might want to access the Account Settings page.

Motivation for or Use Case

Generating a monolith web application with the jhipster command using React as the client-side technology is a VERY common use case for us (and I suspect many others). Changing language selection causes an entire page full of error messages about missing translations, which is a poor user experience. For the second issue described above (mis-titled Settings menu item), this is also not a good user experience for anyone looking to review/modify their user settings.

Reproduce the error

The description to reproduce is summarized above. It is very simple to see these problems in action:

1. create a new application directory which will host your new jHipster monolith application
2. cd into this new directory and type "jhipster"
3. accept default options in the jhipster app generator, except use React as the client framework, and make sure two or more languages are selected for translations, with English as the default language.
4. jHipster 7.9.0 on Linux will present another error during app generation (described in another bug report posted last night). Work around this issue (rimraf command missing and permissions for npmw/mvnw scripts on Linux) so that the app can be run with "./mvnw"
5. The app will start in your local environment (http://localhost:8080). Log in as admin/admin.
6. Select another language from the language menu - text across the page will present errors
7. Select Account menu item. You are logged in as admin, but the Settings menu item shows as "Sign in".

Related issues

I have not previously reported, but did observe the issue in jHipster 7.8.1 - I was hoping 7.9.0 would fix it, but that is not the case.

Suggest a Fix

For both of the issues described above, the React code generator needs to be updated. This issue is not present when generating a monolith with Angular or Vue. Comparing code in JH7.8.1 with previous versions of jHipster might help identify the source. I have not yet had an opportunity to find the specific cause.

JHipster Version(s)

7.8.1, 7.9.0

JHipster configuration

{ "generator-jhipster": { "applicationType": "monolith", "authenticationType": "jwt", "baseName": "helloworld", "blueprints": [], "buildTool": "maven", "cacheProvider": "ehcache", "clientFramework": "react", "clientPackageManager": "npm", "clientTheme": "none", "clientThemeVariant": "", "creationTimestamp": 1659361869299, "databaseType": "sql", "devDatabaseType": "h2Disk", "devServerPort": 9060, "dtoSuffix": "DTO", "enableGradleEnterprise": false, "enableHibernateCache": true, "enableSwaggerCodegen": false, "enableTranslation": true, "entitySuffix": "", "jhiPrefix": "jhi", "jhipsterVersion": "7.9.0", "jwtSecretKey": "ZWFiY2U1NjY0YzUxZGYzNjViNTIyNWQyNmE5MzA2YWYwMDE2MGQ1Z=", "languages": ["en", "fr", "de", "it"], "messageBroker": false, "microfrontend": false, "microfrontends": [], "nativeLanguage": "en", "otherModules": [], "packageName": "company.mycompany.helloworld", "pages": [], "prodDatabaseType": "postgresql", "reactive": false, "searchEngine": false, "serverPort": "8080", "serverSideOptions": [], "serviceDiscoveryType": "no", "skipCheckLengthOfIdentifier": false, "skipFakeData": false, "skipUserManagement": false, "testFrameworks": [], "websocket": false, "withAdminUi": true } }

Entity configuration(s) entityName.json files generated in the .jhipster directory

No additional entities needed to demonstrate issue.

Browsers and Operating System

Tested on latest Chrome and Firefox browsers Mint Linux 20.3, Ubuntu Linux from Windows WSL2

• [X] Checking this box is mandatory (this is just to show you read everything)

[mraible]

I tried to reproduce with your .yo-rc.json. However, I'm unable to log in (step 5).

2022-08-01 10:50:27.582 ERROR 74686 --- [ XNIO-1 task-1] c.m.h.web.rest.UserJWTController : Exception in authorize() with cause = 'NULL' and exception = 'The signing key's size is 312 bits which is not secure enough for the HS512 algorithm. The JWT JWA Specification (RFC 7518, Section 3.2) states that keys used with HS512 MUST have a size >= 512 bits (the key size must be greater than or equal to the hash output size). Consider using the io.jsonwebtoken.security.Keys class's 'secretKeyFor(SignatureAlgorithm.HS512)' method to create a key guaranteed to be secure enough for HS512. See https://tools.ietf.org/html/rfc7518#section-3.2 for more information.'

[idexxt2]

Is it possible that the reason this isn't working is that I modified the key when I posted the .yo-rc.json? The issue submitting form recommended not including any sensitive key information: "You should remove any sensitive information like the rememberMe key or the jwtSecretKey key". I can repost with that key intact if you think that is the source of the issue you are seeing.

[terrytompkins]

Hi @mraible - apologies for taking the bug reporting instructions a bit too literally with a throwaway test app. I recreated both issues on a fresh laptop running Ubuntu Linux from the MS app store under WSL2 on a Windows 11 host. I installed node 16.16.0 (although I have duplicated this with several versions of Node by switching versions via the nvm tool). I then installed a fresh copy of jhipster (7.9.0) and then recreated the app descripted with the .yo-rc.json file above. The ".yo-rc.json" file below contains the complete jwtSecretKey value. This issue has made jhipster demos for my org a bit problematic since the 7.8.1 release back in April, so I would love to see the React frontend code working properly again - thank you! Btw, my home lab has a lot of PC's with different configurations of hardware and operating systems, so I'm happy to test things out on a good variety of Apple, Wintel and Linux hardware/software. -terrytompkins (aka idexxt2) .yo-rc.json: { "generator-jhipster": { "applicationType": "monolith", "authenticationType": "jwt", "baseName": "helloworld", "blueprints": [], "buildTool": "maven", "cacheProvider": "ehcache", "clientFramework": "react", "clientPackageManager": "npm", "clientTheme": "none", "clientThemeVariant": "", "creationTimestamp": 1659400603681, "databaseType": "sql", "devDatabaseType": "h2Disk", "devServerPort": 9060, "dtoSuffix": "DTO", "enableGradleEnterprise": false, "enableHibernateCache": true, "enableSwaggerCodegen": false, "enableTranslation": true, "entitySuffix": "", "jhiPrefix": "jhi", "jhipsterVersion": "7.9.0", "jwtSecretKey": "NzBhNDdiZWQ2OGNiYzU3YTJlMDdiMGNjMjAwZDIxNDJjMzYxMjUzZmQ1N2E5MDBiYmMyMDM5YmUyMTVhODFlZjUwZWUwNjcyZTE1Njk2YTRmMTYwNzgxODA5YWM2Nzk3NDBiYTFiODQxNDUwNTZiOGZjOWNkMDdhZjY0NmViNjk=", "languages": ["en", "fr", "de", "it"], "messageBroker": false, "microfrontend": false, "microfrontends": [], "nativeLanguage": "en", "otherModules": [], "packageName": "com.mycompany.helloworld", "pages": [], "prodDatabaseType": "postgresql", "reactive": false, "searchEngine": false, "serverPort": "8080", "serverSideOptions": [], "serviceDiscoveryType": "no", "skipCheckLengthOfIdentifier": false, "skipFakeData": false, "skipUserManagement": false, "testFrameworks": [], "websocket": false, "withAdminUi": true } }

[mraible]

I was able to reproduce this with your .yo-rc.json. I also saw this in my logs, not sure if it's related:

ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running React 17. Learn more: https://reactjs.org/link/switch-to-createroot

I noticed that if you refresh the browser, the selected language does work.

[mraible]

I added a bug bounty. @qmonmert Can you please take a look?

[qmonmert]

@mraible PR for "switch to createroot" but is does not fix the issue. I will try to fix that soon.

[gmarziou]

The issue submitting form recommended not including any sensitive key information

@terrytompkins jhipster info takes care of removing sensitive information, gives environment data and also includes github formatting, next time please use it.

[idexxt2]

@gmarziou - thank you - that's good to know, and I will follow the process the next time. I have found another couple of issues (related to OpenAPI 3.0), so I'll have a chance to get it right after I set up demonstration apps for the issues.

[qmonmert]

@mshima maybe this commit https://github.com/jhipster/react-jhipster/commit/afba74cf026073d128d06423d32fbd6fe553aae3 caused a regression? Maybe call TranslatorContext.change() but I don't understand very well

[mshima]

I will take a look.

[mshima]

There is a race condition where the ui is refreshed before the translation have been loaded. If you switch the language twice you will see the translation. I will provide a PR.