Create a demo play page for visitors

[yuanchenmeng]

Overview

In this PR, I created a demo play page located at /demo/play for visitors and front end developers for developing purpose. Static dummy data from UserHomeDummy.json is used to fill the content. The demo page only displays static texts so that the front end developers can focus on UI design only without the need to be concerned about security and back end. This PR lays the groundwork for implementing pagination functionality and better UI in the future.

Minor fix

• util: Introduced a parseMoney function that handles value formatting with SI prefixes. The function accepts a double numeric value and scales it using SI prefixes like "K", "M", "B", and so on, to improve readability for large numbers. The previous function uses responses.toFixed(2). The length of integer part may be very long, which hinders future UI design.
• FarmStats.js: parseMoney function is used.
• CommonOverview.js: added additional handlings for the submit button. Logged out users will receive toast messages.

Discussion - Security Concerns

URL end point '/demo/play' is open to public without protection of Google OAuth. If dokku doens't have rate limiting protection, it may be vulnerable to DDoS attacks. I wonder whether it's a secured approach. If it is unsecured, we can use it as a dev branch instead of a production branch.

Screenshots

Tests

Frontend Coverage & Mutation: 100%

Linked Issues

Closes #88 Mid part of #6

[pconrad]

Due to the security concerns, it would be nice if the route is conditionally tied to the env.PRODUCTION variable, that way it will not be accessible on production builds.

Agreed with @iain801 about the security points. If we go forward, we should make this conditional on profile; see these lines for examples of how to do that in the backend:

• FrontendController.java
• FrontendProxyController.java

For the frontend, you'd need to expose something through the systemInfo controller about the current profile.

But what I wonder is this: how is this different from using the existing Storybook and Swagger tools? It seems like it introduces extra complexity, and I'm not sure whether what we get for the developer is worth the extra complexity.

Can you help me better understand the use case for this?

[yuanchenmeng]

Thank you for your valuable feedback. Due to security concerns, I decide to close this PR and this branch will be used as my personal dev branch. I'll bring minor fix in this PR to the PR related to paginated profit table. Regarding my approach, I prefer to use browser development tools initially, working with static content, when designing components from scratch. Additionally, in my opinion, when working on designing components, avoiding unnecessary detours, such as configuring OAuth locally and creating additional Storybook pages, maintains a direct and efficient workflow.