1 - Create the skeleton of the React SPA

[MellyGray]

What this PR does / why we need it:

This PR creates the React application skeleton for the frontend rarchitecture. It provides with a basic skeleton with all the needed configuration to start developing a feature/component for the Dataverse SPA. Additionally, React default component has been replaced by a HelloDataverse component.

Which issue(s) this PR closes:

Closes #1

Special notes for your reviewer:

Changes

• React App with TypeScript
• Jest and Testing Library configured for unit tests
• Cypress for e2e tests
• i18next English language configuration for internationalization
• ESlint and Stylelint for linting
• Prettier formatter
• Workflows for lint and tests
• React Router
• SASS and Bootstrap for stylesheets
• Add HelloDataverse component

React Starter

More common tools:

• Vite. Uses different bundler for production and development. The development bundler is faster but more unstable. This option was discarded because it may be differences between dev and production environments because of this 2 different bundlers.

• Create React App. Uses webpack which is slower but the most stable solution right now. Really easy set up with the integrated scripts. In the future React may change the bundler from webpack to another better solution but our code doesn't know anything about the bundler so it won't be affected. The code is not coupled to the bundler.

Testing

Jest with Testing Library chosen because it allows unit testing of the React components from the user perspective instead of directly testing the business implementation. This means that the unit tests are not modified after refactoring a component because the user should see the same behaviour. Some other libraries check directly the props or states which means that if you refactor a prop variable name then the unit test will stop working.

Cypress has great support for React and Testing Library. It is a widely used solution that works great.

i18next

i18next is already being used in the Dataverse project. It has been configured in the React skeleton because in the very first component there is going to be text to translate, so it is easier to have the i18n configuration from the beginning.

I also see an advantage in not having to see the text in the components because it allows you to see a structure instead of a component with a concrete use case, for example in HelloDataverse.tsx I know there is a translated title but I don't know what the specific text is:

<h1 className={styles.title}>{t('title')}</h1>

It is really recommended to see the video on i18next Introduction

ESlint, Stylelint and Prettier

A basic ESlint configuration has been added, we may want to add more rules in the future or change the existing ones but the configuration is already done to ensure the whole project is following the same linting rules.

It is recommended to run prettier formatted on save, see IntelliJ and VSCode configuration

React Router

From React Router:

React Router enables "client side routing".

Client side routing allows your app to update the URL from a link click without making another request for another document from the server. Instead, your app can immediately render some new UI and make data requests with fetch to update the page with new information.

It has been configured since the beginning because it is going to be used with every new page.

SASS and Bootstrap

Bootstrap is being used in the current Dataverse frontend so it will be used in the SPA too to maintain the UI appearance.

SASS is a really useful CSS extension, it has nesting, mixins and inheritance among other features to help with the CSS maintenance.

In React it can used like:

import styles from './HelloDataverse.module.scss'

<div className={styles.container}>
  <header>
    <h1 className={styles.title}>{t('title')}</h1>
  </header>
</div>

I really like that there is no need to think of class names, you can just call the class name .container in every component and there are not going to be conflicts between any other classes because .container is automatically compiled to the class name .HelloDataverse_container.

This also forces you to not reuse CSS classes between components. Reuse the component, not the CSS class.

Workflows

I added 2 basic workflows to check the linting and the tests. They are configured to run on push and for the moment they are not taking so long. Test (5min) and lint(2min) but if they start to take longer then they might be configured to run only on merge.

The test workflow runs both unit and e2e tests. We may want to split them at some point and for example run the unit tests on push and the e2e on merge.

Hello Dataverse component

HelloDataverse.tsx is just the default Create React Component but adapted to Dataverse to have an overview of what a component would look like and test some initial configurations such as the translation hook from i18n.

This component will be removed once the first feature is developed.

Suggestions on how to test this:

Install node v19 and npm v9.

Run npm install

Run npm run start and go to http://localhost:3000 to see the application

Run npm run test for the unit tests

Run npm run cy:run for the e2e tests

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Hello Dataverse screen If you cannot access the screen please contact melinahernandez@theagilemonkeys.com

Is there a release notes update needed for this change?:

Not sure, the Hello Dataverse component will be removed for the release, but the skeleton will remain.

Additional documentation:

Dataverse - SPA Development Strategy

[pdurbin]

• Vite. Uses different bundler for production and development. The development bundler is faster but more unstable. This option was discarded because it may be differences between dev and production environments because of this 2 different bundlers.

• Create React App. Uses webpack which is slower but the most stable solution right now. Really easy set up with the integrated scripts. In the future React may change the bundler from webpack to another better solution but our code doesn't know anything about the bundler so it won't be affected. The code is not coupled to the bundler.

Can we please talk a little more about Webpack vs. Vite? I am by no means an expert in this matter but mostly from podcasts I listen to, I get the impression that Vite is faster and more modern than Webpack. (The same observation about speed is already above.) I also get the impression that the "cool kids" are moving away from Webpack.

I understand the part about Create React App might switch away from Webpack to something better in the future. I don't see a direct dependency on Webpack in our package.json so it does seem like the code is not hard coded to use Webpack.

Vite was discarded because "may be differences between dev and production environments because of this 2 different bundlers"? I'm having trouble understanding what this means. In short, I'm wondering if we can use Vite. And if not, why not. 😅

We can talk this out in Slack or in our weekly meetings, of course, I just wanted to put this here in case we're close to merging this pull request (I have no idea).

[MellyGray]

• Vite. Uses different bundler for production and development. The development bundler is faster but more unstable. This option was discarded because it may be differences between dev and production environments because of this 2 different bundlers.
• Create React App. Uses webpack which is slower but the most stable solution right now. Really easy set up with the integrated scripts. In the future React may change the bundler from webpack to another better solution but our code doesn't know anything about the bundler so it won't be affected. The code is not coupled to the bundler.

Can we please talk a little more about Webpack vs. Vite? I am by no means an expert in this matter but mostly from podcasts I listen to, I get the impression that Vite is faster and more modern than Webpack. (The same observation about speed is already above.) I also get the impression that the "cool kids" are moving away from Webpack.

I understand the part about Create React App might switch away from Webpack to something better in the future. I don't see a direct dependency on Webpack in our package.json so it does seem like the code is not hard coded to use Webpack.

Vite was discarded because "may be differences between dev and production environments because of this 2 different bundlers"? I'm having trouble understanding what this means. In short, I'm wondering if we can use Vite. And if not, why not. 😅

We can talk this out in Slack or in our weekly meetings, of course, I just wanted to put this here in case we're close to merging this pull request (I have no idea).

Hi @pdurbin ! I'll try to answer you here just to keep the answer here for future reference, but we can still discuss it in the weekly meeting

I know many people is choosing Vite over CRA, mostly because of the speed of Vite during the development

What I meant by "there may be differences between dev and production environments" is because Vite pre-bundles dependencies using esbuilt for the local development but it doesn't use it for the production build, so there may be inconsistencies between local and production build. It doesn't give me confidence that they do not use their esbuilt super fast solution for the real production build.

For me there was a decision, speed or stability, and I chose stability because I don't see that major difference in speed. I have used both Vite and CRA in different projects and I still haven't seen that speed difference. Stability and reliability I think is more important when speaking about a large and complex project like this one.

Moreover, CRA is designed specifically for React and it has a higher level of customisation than Vite, because Vite is designed to be a simple, fast solution, not just for React but for any project using JavaScript. I prefer that higher level of customisation because this is going to be a huge project and we don't know what we are going to need in the future, how specific do we need to get with the project build.

I hope I explain it better this time, and of course we can move to Vite if CRA still doesn't convince you 🙂

[pdurbin]

Vite pre-bundles dependencies using esbuilt for the local development but it doesn't use it for the production build, so there may be inconsistencies between local and production build. It doesn't give me confidence that they do not use their esbuilt super fast solution for the real production build.

For production builds, Vite uses Rollup, which is very popular. In all cases ES Modules are used so I'm not worried about inconsistencies.

For me there was a decision, speed or stability, and I chose stability because I don't see that major difference in speed. I have used both Vite and CRA in different projects and I still haven't seen that speed difference. Stability and reliability I think is more important when speaking about a large and complex project like this one.

Dataverse is built on stable tools like PostgreSQL, Solr, and the Jakarata EE APIs so I'm easily convinced by the stability argument. However, while CRA the technology seems stable enough, CRA the project shows some warnings signs.

Just yesterday I was listening to a podcast where the creator of Svelte said, "You mentioned Create React App, which is essentially a single page app framework, even the React team are now trying to get rid of. It kind of codifies a lot of bad practices."

The React team is trying to get rid of CRA? Is that right? I googled and easily found a long comment from only a month ago by CRA co-creator Dan Abramov who had this to say:

"As the years passed, Create React App has stagnated."

"We could suggest people to migrate from Create React App to something like Vite."

He lays out five options for the future for CRA, from a huge rewrite to smaller endeavors. He says the React team is leaning toward option 5, which even mentions possibly moving to Vite under the hood:

"Option 5: Turn Create React App into a launcher

We could keep Create React App as a command, but turn it into a launcher. It would suggest a list of recommended frameworks, followed by the "classic" framework-less approach being the last option. That last "classic" approach would produce a client-only app like CRA does now (to avoid breaking tutorials), but could eventually move to Vite under the hood."

This leave me wondering, with so much talk of Vite from the creators of CRA, why not just use Vite?

Finally, to go back to the speed option, Dataverse is a big app and I do think we should be concerned about speed. Speed should be a feature. (That's what the creators of Stack Overflow said.)

Moreover, CRA is designed specifically for React and it has a higher level of customisation than Vite, because Vite is designed to be a simple, fast solution, not just for React but for any project using JavaScript. I prefer that higher level of customisation because this is going to be a huge project and we don't know what we are going to need in the future, how specific do we need to get with the project build.

I heard you on this concern. I'm sure we'll want customization. I just don't know if using Vite will be a problem in this regard or not. I guess we'll learn more if we try Vite.

[pdurbin]

As discussed at standup just now, I'm very happy with this pull request overall. Great job, @MellyGray! My one outstanding concern is about using Create React App rather than Vite and (as discussed), I created a separate issue for that:

• #10

Meanwhile, I think this is ready for QA and merging. I ran the code early on but that was a couple weeks ago.