Migrate to latest version of react, react-dom, react-redux, and redux

[1fifoto]

We are presently on react v16. This is to move ahead to v17. Also update redux to get hooks such as useStore. I have tried just installing this, but some breakage occurred and I didn't have time to pursue and fix the problem(s). So I regressed back to v16 and will do this as a separate issue and effort.

[1fifoto]

Also consider react-bootstrap and Bootstrap v5.

See issue #637.

DONE: client's package.json now at

"bootstrap": "^5.3.3",
"react-bootstrap": "^2.10.1",

[1fifoto]

We are at the latest recommended nodejs version which is version 14.17.0. There is a version 14.18.1, but not especially needed to go up to that minor update level.

DONE: now at:

brianwatt@Bris-M1-MBP odop % node -v
v20.11.1

[1fifoto]

Eclipse update might need to be considered because Mike is getting a warning message about being downlevel with nodejs version 14 and having eclipse only support nodejs version 12 and earlier.

DONE: See previous scomment.

[1fifoto]

Consider updating okta packages too. Note: okta-react has a dependency on "react": ">=16.8.0" even though the latest react is 18.1.0. I don't know if this limits us to use an earlier version of react.

Consider updating node from engine 14 to engine 16 which has long term support until 2024. In our package.json we have the following stanza

"engines": {
  "node": "14.x"
},

DONE: now at Okta:

"@okta/okta-react": "^6.8.0",
"@okta/okta-signin-widget": "^7.18.0",
"@reduxjs/toolkit": "^2.2.1",

Changed server's package.json to:

"engines": {
    "node": "20.x"
},

[1fifoto]

Moved to Node 18.13.0.

DONE: see above, now at v20.11.1

[1fifoto]

Latest LTS for Node is now 18.17.1

DONE: We have moved to Node 20. From the Node website:

The 20.x release line now moves into "Active LTS" and will remain so until October 2024. After that time, it will move into "Maintenance" until end of life in April 2026.

[grumpyinca]

Test result number 18
low priority as written; medium priority to the extent that there are related cases with greater impact

May 01 Slack entry. Confirmed July 20, 2024.

I did a pull to get the latest of branch 441.
The development system will switch to Advanced View anytime that the design type is changed.  
I confirmed that the staging system (v4.5.1rc1) maintains the selected view when switching design types.  

While I do not consider it to be a high priority, I think that maintaining the view across a design type change is my preferred behavior.  	
Considering that all but the most experienced users go back to SpringDesignSoftware.org to switch design types or 
switch Advanced versus Calculator View, the actual behavior will impact relatively few users.  
Those users it does impact will be those that are most likely to consider it a minor inconvenience. 

DONE: Switching from the default Advanced View to Calculator view now worked when changing to different types of Spring models. When switching from a Spring model in Claculator view to a Solid or Piston-Cylinder model the system must switch the view from Calculator to Advanced because Solid or Piston-Cylinder do not have a Calculator view. Once switched the view and returning to a Spring model does not restore Calculator, but instead remains switched to Advanced view.

[grumpyinca]

Test result number 19
high priority

May 01 Slack entry. Confirmed July 21, 2024
Anytime that I attempt adding query parameters to localhost:3000,
for example: http://localhost:3000/?type=Spring%2FExtension&view=Calculator&execute=demo6,
I get a red pop-up with the text: "GET of 'Startup' design failed for type 'Spring/Extension' with message:
'startExecute is not defined' "
Note that: https://odop-staging.herokuapp.com/?type=Spring%2FExtension&view=Calculator&execute=demo6
produces the expected result on the staging system.

DONE: Added import for startExecute.

[grumpyinca]

Test result number 20
Very low priority

May 03 Slack entry. Confirmed July 20, 2024.
Advanced View row height in branch 441 is greater than the row height in staging.
The actual situation might be browser dependent.
I have screen captured two MS Edge windows side-by-side. Branch 441 on the left, staging on the right. See screen capture in May 03 Slack entry.
Do you see the same thing with Chrome and Safari ?
In any case, this is a very low priority problem.

[grumpyinca]

Test result number 22
low priority

June 14. Confirmed July 20, 2024.
Message that briefly appears in development environment client command window when loading:

(node:9656) [DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE] Deprecation Warning: 'onAfterSetupMiddleware' option is deprecated. 
Please use the 'setupMiddlewares' option.
(Use `node --trace-deprecation ...` to show where the warning was created)
(node:9656) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated. 
Please use the 'setupMiddlewares' option.

[grumpyinca]

Test result number 23
priority - see note at end of this comment

June 14. Confirmed July 20, 2024
During Seek Min Weight on extension spring, multiple console warnings similar to:
updateObjectiveValue.js:147 (& lines 46, 144, 161, 164) SerializableStateInvariantMiddleware took 46ms, which is more than the warning threshold of 32ms. If your state or actions are very large, you may want to disable the middleware as it might cause too much of a slowdown in development mode. See https://redux-toolkit.js.org/api/getDefaultMiddleware for instructions. It is disabled in production builds, so you don't need to worry about that. Alerts.jsx:242 SerializableStateInvariantMiddleware took 69ms, which is more than the warning threshold of 32ms. If your state or actions are very large, you may want to disable the middleware as it might cause too much of a slowdown in development mode. See https://redux-toolkit.js.org/api/getDefaultMiddleware for instructions. It is disabled in production builds, so you don't need to worry about that.

Note on priority

These warning messages alone are not a great concern, particularly in that they seem to be disabled in production. However, work on these messages will likely lead to work on more general performance issues (and spinner) that are likely outside the scope of issue #441. See Test result number 29 below. If the general performance issues are resolved, then it is likely that these messages will be resolved. So, in summary, while the priority of eliminating these messages is low, work to eliminate the messages may overlap with higher priority work outside the scope of issue #441. It may be best to defer work on these messages.

[grumpyinca]

Test result number 28
high priority

June 15. Confirmed July 20, 2024.
Extension spring demo7 produces a different search result than the staging system.
The value of FORCE_1 MIN start to diverge on page 5 of 11.
It seems that setting the value of Force_1 MIN to 45 did not work in branch 441.
Transitioning page 6-->7 of 11 takes much longer wall clock time to produce a lower value of OBJ in fewer iterations.
I think that there is an FDCL issue here.

From demo7. Somewhere around there is when it diverged. See macro statements below:

            resetSymbolFlag('Force_1', MIN, FDCL),
            setSymbolFlag('Force_1', MIN, CONSTRAINED),
            changeSymbolConstraint('Force_1', MIN, 45.0),
            setSymbolFlag('Force_1', MAX, CONSTRAINED),
            changeSymbolConstraint('Force_1', MAX, 55.0),

DONE - Aug 7, 2023

Confirmed fixed - August 10, 2024

[grumpyinca]

Test result number 29
medium priority

June 23
Performance concerns: compression spring demo10 is my recommendation for a test case to reproduce the performance problem.

June 23 3:30pm PST Slack entry:
Performance testing:
A quick review of demo sessions discovered that in compression spring demo10, the transition from page 09 to page 10 of 15 contains a search that runs for 70 iterations.
I set up my two VMs side-by-side. The left side was the branch 441 development environment (v5.0dev). The right side was the master branch development environment (v4.6dev).
I used the stopwatch app of my smartphone to do the timing.
The average page 9 to 10 transition time for branch 441 was roughly 21 seconds. The average page 9 to 10 transition time for the master branch was roughly 1.5 seconds.
If you want to run this test many times and eliminate having to hit "Next" a bunch of times, it would be pretty easy to create a stripped-down version of the demo10 script.
Just a side observation ... many operations (demo page transitions) in branch 441 are perceptibly slower than their equivalents in the master branch. So, my guess is that the root performance issue is pretty low-level and impacts a lot more than just Search. Using a Search that requires a large number of iterations makes for a good test case because it makes the differences easy to see. Also, Search is so fundamental to the app, it provides confidence that we are not wasting time on some rare corner case.
Let me know if you think that I can do more along these lines.

[grumpyinca]

Test result 30
high priority

June 29. Confirmed July 21, 2024.
"Redirect" of local storage is causing problems when logging in.
Symptoms are an empty (blank) browser window after login.

MS Edge workaround for blank screen after attempting login:

1. F12 to launch DevTools
2. +
3. Application
4. delete "redirect"

DONE: Conversion typo from the old reducers code to the new redux model slice code has been repaired.

Confirmed fixed ~ Aug 04, 2024

[grumpyinca]

Test result 31
High priority
Discovered August 1, 2024

Steps to recreate:

1. Reload app.
2. Change the value of any independent variable. For example, change the value of OD_Free from 1.1 to 1.2.
3. Observe traceback. Note that message below repeats 4 times.

Uncaught runtime errors:
 
ERROR
model_system_controls is not defined
ReferenceError: model_system_controls is not defined
    at Object.onChangeValidLocal [as onChangeValid] (http://localhost:3000/static/js/bundle.js:8057:5)
    at localOnChange (http://localhost:3000/static/js/bundle.js:5701:60)
    at HTMLUnknownElement.callCallback (http://localhost:3000/static/js/bundle.js:219591:18)
    at Object.invokeGuardedCallbackDev (http://localhost:3000/static/js/bundle.js:219635:20)
    at invokeGuardedCallback (http://localhost:3000/static/js/bundle.js:219692:35)
    at invokeGuardedCallbackAndCatchFirstError (http://localhost:3000/static/js/bundle.js:219706:29)
    at executeDispatch (http://localhost:3000/static/js/bundle.js:223849:7)
    at processDispatchQueueItemsInOrder (http://localhost:3000/static/js/bundle.js:223875:11)
    at processDispatchQueue (http://localhost:3000/static/js/bundle.js:223886:9)
    at dispatchEventsForPlugins (http://localhost:3000/static/js/bundle.js:223895:7)
ERROR 

(repeats 3 more times)

DONE: Fixed 2024-08-02 14:01

Confirmed fixed ~Aug 04, 2024

[grumpyinca]

Test result 32
Medium priority to fix traceback
Low priority to make behavior match staging/production or implement a design philosophy.
Discovered August 3, 2024

Traceback when switching to a new model (design) in mid Execute file (Help : Demo).

Procedure to recreate (From Slack):

1. File Open Extension Spring Startup
2. Help Demo demo7
3. File Open Compression Spring Startup
4. Error: Cannot find module './Spring/Compression/demo7.js' with traceback

Repairing this issue invokes a number of design / philosophy questions. What should happen to the in-progress execute session when various operations (Load initialState, Log in/out, File : Open, File : Import, Login during File : Open, etc.) take place? See issue #920 titled: "Sign-in when running Execute clears the Execute".

DONE. Fixed Aug 11, 2024

Traceback confirmed fixed: Aug 15, 2024

[grumpyinca]

Merged to master on Aug 11. Expect to close soon after a bit more testing.

[1fifoto]

Merged into master, closing