# Frontend 2.0

## OKRs

The OKRs below aim at providing a frontend setup/experience that "just works", enabling higher levels of productivity and organisational growth.

### Faster Asset Compilation Times

#### Goal
Make both CI and local development faster

#### The Work

1. Configure ViteJS (which leverages esbuild) as our standard bundler toolchain.
3. Can we leverage https://turbo.build/pack over ViteJS or in combination?
4. Investigate the possibility of introducing https://turborepo.org in order to optimize the workflow by caching the result of transpiling and bundling our NPM packages so that local env nor CI ends up doing unnecessary work. There's a chance we may be able to share a remote cache between local envs and CI, potentially giving us asset bundling within seconds.

### Smaller Bundle Sizes (Optimized Code Splitting)

#### Goal

Improve page load times by reducing the amount of JS and CSS assets loaded on every page refresh.

#### The Work

1. Optimize our current code splitting rules and package configurations so that tree shaking can be performed properly by the bundler, therefore, yielding smaller bundle/chunk files;
1. Leverage lazy loading so that chunks are dynamically loaded when absolutely needed, example: there's some javascript/css assets belonging to apps living under the Power menu that could be loaded only when the menu is opened rather than when the page is loaded.
1. Investigate the possibility of introducing SSR (Server Side Rendering) so that less JS code needs to be shipped to the client.

### Better Monorepo Tools

#### Goal

Leverage more modern monorepo tools for managing workspace dependencies and running tasks across multiple Nitro Components

#### The Work

1. Ensure the dependency graph for all packages in the monorepo is well-defined;
2. Leverage the most recent yarn version which provides better monorepo tools for managing dependencies across multiple packages as well as running tasks across workspaces.
3. Look into [Yarn's Plug'n'Play](https://yarnpkg.com/features/pnp) as an alternative to the traditional `node_modules` resolution algorithm in order to speed up dependency resolution.
4. Look into the possibility of using https://pnpm.io to speed up dependency resolution in case Yarn Plug'n'Play proves to be problematic.

### Improved DX (developer experience)

#### Goal

Provide developers with a faster feedback look when developing frontend applications by standardizing and configuring tools to help in the development workflow.

#### The Work

1. Configure eslint and prettier with the rules we agreed to follow;
2. Sentry Source Maps;
3. Leverage https://storybook.js.org as our official development environment for React. This project can help us better document resuable components within Nitro that don't belong in Playbook, generate test reports, provide a responsive testing environment, Pixel perfect testing, improved component discoverability, allow developers to work on components in isolation, etc...
4. Restructure `nitro_react` into smaller modules to be consumed in isolation:
- `nitro_react/graphql`: Module providing reusable graphql capabilities
- `nitro_react/forms`: Module providing standard form utilities, example: form element adaptors to make it easier to use certain Playbook kits with react-hook-forms, helper hooks for simpler form use cases (e.g. `const input = useInput()`)
- `nitro_react/hooks-utils`: Collection of generic/resuable hooks, example: `usePersistedState()`, `useMediaQuery`, `useToggler`, etc...
- `nitro_react/kits`: Collection of React components that could eventually be promoted to Playbook. Think of experimental components that once proven could be extracted into Playbook.
5. Update the component generator to bootstrap an NPM Nitro Component with all the standard tooling already configured;
6. Implement a cobra command to update an existing Nitro Component with the new tooling/setup proposed here.

### Mature Frontend Testing

#### Goal

Provide more modern testing tools as well as standardize testing patterns to be followed by frontend apps in an effort to create and foster a more mature testing culture for frontend applications.

#### The Work

1. Set up more modern testing libs such as [react-testing-library](https://testing-library.com/), [react-hooks-testing-library](https://react-hooks-testing-library.com) to help with unit testing JS code;
1. Set up an e2e test environment (using Cypress) on a component basis, so that frontend apps can implement better e2e/system test coverage.
1. Enable proper debugging workflow in specs

## Adhoc Notes

- Increased page load times due to loading too many unnecessary webpack assets (css, js, images)
- Look into dynamic imports to improve code splitting; Some packs don't have to be loaded until users click something like a menu option (Power P button has a lot of tiny react apps that could be lazy loaded)
- Look into tree shaking for our NPM packages (especially nitro_react); Options:
- Remove the `export {...} from "..."` and force clients to import the modules directly;
- Look into setting `side-effect` to false to nitro_react's package.json so webpack (and soon Vite) know it can safely tree shake the package.
- Dependency Management;
- yarn vs npm vs [pnpm](https://pnpm.io)
- Dependency Resolution;
- pnp vs node_modules
- Asset Bundling;
- webpack vs vite vs turbopack
- Asset Delivery;
- chunks vs static vs SSR
- Speed up compilation;
- Better dependency management tooling;
- Upgrade to latest yarn version which provides better workspace management;
- Use pnp for faster dependency graph resolution;
- Ensure Nitro Components have their dependencies well defined and don't rely on them to be "magically" available in the yarn workspace;
- Simpler bundling setup;
- webpack is just too complex;
- The amount of babel plugins required is insane and make managing these deps harder;
- Asset compilation per Rails engine;
- Helps encapulating concerns making sure each Nitro Component is resposible for compiling the assets that belong to them;
- Potential for parallel compilation? Nitro components compiling assets in parallel?
- Improved dev setup;
- Faster `yarn hmr`;
- Better linting;
- Better code formatting (prettier);
- Can we leverage turborepo for caching tasks and prevent redundant work from being done?
- Can we leverage turbopack over vitejs for even faster bundling? It's alpha version at the moment so probably not an immidiate option.
- Migrate to react-router-dom v6 to enable better data fetching patterns (similar to what Remix does). The migration process is very straightforward when using the [backwards compatibility package](https://reactrouter.com/en/main/upgrading/v5).
- introduce storybook.js.org as a dev env