New Frontend POC

[perebusquets]

As discussed in #225 , this is a proof of concept for a next gen frontend for Movary.

For now, this only contains the login page (without any routing and logic).

In order to avoid having another server in the stack, the way this works, is by placing the built files in the existing public folder. Then, whenever a request comes in, it loads a basic twig template where it loads the assets (mainly the JS and CSS).

For now this twig template is only being used in here in a rather hacky way (with a conditional and a env var). If anyone can provide a better solution for this, where it gets implemented everywhere (maybe in a middleware when it's implemented #235 ?) would be very much appreciated.

Also, right now we're using the ENV variable to know if we need to load from the Vite development server (when in development), or serve the built assets in public/frontend when in production.

Implemented features:

• Frontend with Vite for development + SWC for building.
• Template in twig to integrate with the current server.
• Mantine as UI library (right now with the default theme, could be customized in the future).
• Login page with working calls to the server as an example for other developers to start working on it.
• ReactQuery for managing the state with the server.
• React Router.
• i18next, with a custom backend to use Vite to build and serve the translation files.

Pending requirements from the backend before we move to this frontend:

• Add a way in the server to render the new twig template based on an env var (this way, we can transition more smoothly into the new frontend and give the users an opportunity to try out the new frontend without removing the old frontend in case we miss some functionality).
• Do endpoints (REST, GraphQL,...) that accept/return the requests/responses in the body, instead of URL encoded GET and POST requests. The problem now is that after executing the login, the server does a redirect and returns a twig template, which makes impossible for the new frontend to know which path it should go to to show the dashboard.

To test locally:

Simply start docker, and make sure that the USER_ID in the .env is the user on your local machine. Also add NEW_FRONTEND=1 to load the new template.

[JVT038]

So I honestly have no experience with React, so I can't really judge this.
What you've written in this issue sounds promising, but @leepeuker would need to look at this as well.
Either way, I'm looking forward for the implementation of this!

[JVT038]

BTW, assuming this replaces all the hardcoded strings with the translations, in the html templates, can you also use this to replace the hardcoded strings in the JS /PHP files?

[leepeuker]

@JVT038 I talked about this POC in the github issue

[perebusquets]

Hi @JVT038 ! Thank you for showing your interest in this.
To respond to your last question, this doesn't replace the hardcoded strings in the current templates.
This implementation of translations just works with the new frontend, where by calling the funcion t from the library i18next it replaces the given key for the translation.
Since this library only runs in JS, at the time of rendering, it would be impossible to use after PHP has rendered the templates.