Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add lazy import for different routes #656

Merged
merged 2 commits into from
Jul 9, 2023

Conversation

Sudhanva-Nadiger
Copy link
Contributor

  • imported routes from lazy imports
  • added suspense wrapper around all pages

What

  • since there are many routes in the app, we can delay js bundle file downloads by adding lazy imports

Screenshot

Build Results

  • Without lazy import
    image
  • With lazy import
    image

- imported routes from lazy imports
- added suspense wrapper around all pages
<td>
<a
target="_blank"
href={off.getProductEditUrl(code)}

Check warning

Code scanning / CodeQL

Client-side URL redirect Medium

Untrusted URL redirection depends on a
user-provided value
.
- when file is still loading data wont be there. so added the check if
its is not null in opportunities.tsx
@Sudhanva-Nadiger
Copy link
Contributor Author

@alexfauquette I tested this in my local machine with the hosted website! it worked :)!! But i was thinking that we should probably add tests to make sure things are not breaking while improving the code base.

@alexfauquette
Copy link
Member

Hi, Effectively having tests to ensure all games are still working could be nice. But for now, there is nothing so it's to build from scratch

About reducing the bundle size, you might be interested by the webpack.config.js files. It comes from the first version of this project (more than 5 years ago) and I never touched it. What I understand is that it tends to merge all the files in a single one.

@Sudhanva-Nadiger
Copy link
Contributor Author

When I build it made chunks of js files!
image

and webpack does make chunks of js files when using react lazy imports (ref: https://uploadcare.com/blog/lazy-loading-in-webpack/)
image

@Sudhanva-Nadiger
Copy link
Contributor Author

So should I close this pr ?

@alexfauquette
Copy link
Member

So should I close this pr ?

I tested it too and it's fine so we can merge it if you want, but I struggle to understand the benefit.

  • The first one is personal (pure feeling): I never felt the interface was long to download. It's more call to the different API that take times
  • The second one is technical: Your PR split pages (about 10 different pages) but the result if 4 JS files. So their might be a problem somewhere

It seems that if you don't use the webpack config (run yarn build:react instead of yarn build) you get much more JS files. I did not try to if it was working or not

@VaiTon would you have an opinion on this topic?

@Sudhanva-Nadiger
Copy link
Contributor Author

There is only 4 chunks ! rest all are maps and license, even with normal one it happens

image
image

@Sudhanva-Nadiger
Copy link
Contributor Author

Sudhanva-Nadiger commented Jul 6, 2023

The first one is personal (pure feeling): I never felt the interface was long to download. It's more call to the different API that take times

I am not sure either,
but what I feel is: when we have room for the decrement of the initial load/improvement then why not?

@VaiTon
Copy link
Member

VaiTon commented Jul 7, 2023

The second one is technical: Your PR split pages (about 10 different pages) but the result if 4 JS files. So their might be a problem somewhere.

I think there is a problem about having react-scripts and webpack. The build commands run them sequentially, but they do the same thing. In fact the react-scripts build is splitted more than the webpack build as far as I understand. I tested a clean build with only yarn build:react and it seems to work.

I recommend removing the other command.

@VaiTon
Copy link
Member

VaiTon commented Jul 7, 2023

In the long run I'd recommend switching to Vite too

@VaiTon
Copy link
Member

VaiTon commented Jul 7, 2023

The build commands run them sequentially, but they do the same thing.

Ok so I read again the webpack file, and it appears that it takes the chunks and output a bundle.min.js, which is then unused.

From the README

Use a simple webpack config to bundle in a single file (build/bundle.min.js) and facilitate integration in OFF main site

@VaiTon
Copy link
Member

VaiTon commented Jul 7, 2023

I've created #657 for the webpack issue

@VaiTon
Copy link
Member

VaiTon commented Jul 7, 2023

Also, for me this branch run with yarn build:react produces

Compiled successfully.

File sizes after gzip:

  281.01 kB  build/static/js/main.e66acd1a.js
  83.42 kB   build/static/js/996.15642c50.chunk.js
  26.14 kB   build/static/js/416.d8f9f62d.chunk.js
  13.92 kB   build/static/js/865.6d0cd710.chunk.js
  12.97 kB   build/static/js/635.1a264e73.chunk.js
  12.01 kB   build/static/js/247.992838d8.chunk.js
  11.85 kB   build/static/js/81.8b4229f5.chunk.js
  9.2 kB     build/static/js/636.09ffedf7.chunk.js
  8.68 kB    build/static/js/915.7c9d507e.chunk.js
  8.48 kB    build/static/js/250.a74eb122.chunk.js
  8.24 kB    build/static/js/994.f77743c9.chunk.js
  7.11 kB    build/static/js/182.75d07425.chunk.js
  6.98 kB    build/static/js/713.85a70955.chunk.js
  6.69 kB    build/static/js/848.40591dcf.chunk.js
  6.1 kB     build/static/js/609.4b4f8846.chunk.js
  5.86 kB    build/static/js/965.6653e7a5.chunk.js
  5.31 kB    build/static/js/861.0f881878.chunk.js
  4.97 kB    build/static/js/752.c72f6729.chunk.js
  4.95 kB    build/static/js/331.fea3d7e7.chunk.js
  4.94 kB    build/static/js/230.58cd0b2d.chunk.js
  4.78 kB    build/static/js/59.cc5a4fcf.chunk.js
  4.41 kB    build/static/js/97.1899b77a.chunk.js
  4.04 kB    build/static/js/557.71266763.chunk.js
  3.72 kB    build/static/js/424.47c62fd0.chunk.js
  3.71 kB    build/static/js/44.d44f2428.chunk.js
  3.71 kB    build/static/js/369.99374898.chunk.js
  3.6 kB     build/static/js/964.8fe29e93.chunk.js
  3.55 kB    build/static/js/849.0b6340b0.chunk.js
  3.41 kB    build/static/js/595.a8885faf.chunk.js
  3.38 kB    build/static/js/280.51f7ffc8.chunk.js
  2.75 kB    build/static/js/854.8c0f7acb.chunk.js
  2.62 kB    build/static/js/358.265755dd.chunk.js
  2.57 kB    build/static/js/900.c60f7e12.chunk.js
  2.54 kB    build/static/js/378.f2122baf.chunk.js
  2.48 kB    build/static/js/425.5b353d8c.chunk.js
  2.47 kB    build/static/js/588.871fe44d.chunk.js
  1.55 kB    build/static/js/5.5fa67bab.chunk.js
  942 B      build/static/js/563.80b37c33.chunk.js
  507 B      build/static/js/650.921ce724.chunk.js
  323 B      build/static/js/493.70854ce4.chunk.js

@alexfauquette
Copy link
Member

Yes, I think the "facilitate integration in OFF main site" was an initial idea that never got implemented

@teolemon could you confirm the main website does not show directly hunger games?

@teolemon
Copy link
Member

teolemon commented Jul 7, 2023

The only thing left: https://world.openfoodfacts.org/hunger-game

@Sudhanva-Nadiger
Copy link
Contributor Author

In the long run I'd recommend switching to Vite too

Yess the tooling is next level, and also hmr is great ! Makes development process great !

If we are moving from webpack to vite there is a plugin for migration: https://github.com/originjs/webpack-to-vite

@alexfauquette
Copy link
Member

Yess the tooling is next level, and also hmr is great ! Makes development process great !

Ok, I don't know that much about this framework, I assume it's similar to NextJS

Should we close this PR and open a new one with vite?

@VaiTon
Copy link
Member

VaiTon commented Jul 8, 2023

@alexfauquette we could still use lazy loading. So we could merge this and then I'll open a PR to use Vite.

@VaiTon VaiTon mentioned this pull request Jul 8, 2023
@VaiTon VaiTon merged commit b9d4f93 into openfoodfacts:master Jul 9, 2023
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants