When I run npm run build a build directory is created with js chunks. I have noticed that there is a [number].[hash].chunk.js file that is not listed as one of the entrypoints in the asset-manifest.json file.
Instead, this file appears to be referenced in the runtime-main.[hash].js file.
What is the purpose of this file? I have noticed that in it's map file it references web-vitals.js. Do I need to make sure that my application will be able to access this file? Is it critical to the application's performance?
This is a react app was created with typescript using npx create-react-app my-app --template typescript
At build time your bundler (webpack) will determine what code is necessary for the main entry bundle and which code can be loaded later (aka. lazy loading). It will also determine which files are shared by different entry points and will bundle them as a shared asset. This allows your application to load quicker on initial load - only loading the resources it needs when they're needed.
There are complex algorithms which determine how to split code in a way which is beneficial to both end users and your server/network. In general, don't try to analyze it. You can trust that the people writing the algorithms are smart and striving for the greater good, and it's always getting better.
NOTE: I used to work for a company that built a bundler and implemented code splitting long before webpack, rollup, and friends came along. The bundler was used for years for the likes of Sam's Club, Levi's, and some fruit company. It did not take long for webpack and rollup to surpass the one we had built, but I still have a pretty intimate understanding of how it all works, and the guys who built it were some of the smartest people I've ever met. You don't really need to understand the output files - I highly doubt there are any unnecessary files being generated.
Related
In a bigger project, I have a fairly high amount of used third-party libraries, including firebase, redux, etc and some more specific ones (but only used on several pages) like konvaJS, jimp, ....
I just migrated recently to nextJS to speed up the website & maybe allow SSR. However, after migrating, the Lighthouse Speedtest dropped compared to the Pure React Version. The main problem seems to be the shared JS first Load bundles.
After some optimizing, including lazy loading bigger Components with dynamic() & modules with await import(), I managed to compress the shared first load JS bundles by half, but they are still around 400KB which is way too heavy. I guess heavy modules like firebase are included there as well, because it is needed basically everywhere in the App.
I also tried to analyze the dependencies with #next/bundle-analyzer. But the Visualization is not really easy to interpret. Is it true that it also lists modules that are lazy loaded? And in addition, I have some dependency packed multiple times in different bundles. Last but not least, the bundles visualized by the analyzer do not match the names of the build output.
Any help to reduce or understand the process better is well appreciated. I am using current React & Next.js versions.
Edit: This is the composition of the shared JS bundles after build:
Edit2: I am still confused about the output of bundle-analyzer. The module jspdf for instance, is only used in one page / component and lazy loaded. Is it correct that it is still visible in the analyzer? It does not have any impact on the shared JS bundle size.
Edit3: I managed to lazy load my firebase modules (which are crucial for my App), so I saved over 200KB shared JS size. Still hoping to cut down the remaining. Btw, the bundle analyzers output did not really change.
Are you using FontAwesome?
We were able to reduce our "First Load JS shared by all" from
504kb down to 276kb
by removing FontAwesome dependency and downloading the individual .svg icons
directly.
Before
After
Me and my team are making a React website. We've done all the coding bits, however, I'm worried that with more people joining in, our code-base can become messy, as in:
Improper indentation used (preferred 2 space in .js files)
Extremely long lines (I'd prefer to set a limit for number of lines in a row)
Incorrect location of CSS files: For e.g. storing .css files under components (I'd prefer them to be in src/ but outside src/components/)
No Warnings when running npm start.
From the little I've tested out testing libraries for React, they mostly deal with code errors. I'm aware in Android it is possible to keep checks for first two options using testing libraries. What are React/NodeJS solutions for the same?
You can use Prettier to format you code with just one command in editors like Visual Studio code.
Incorrect location of CSS files: For e.g. storing .css files under components (I'd prefer them to be in src/ but outside src/components/)
There is no way to automate this as far as I know, but this should be possible by setting the right example first and communicating your preference.
I have had a developer create a website or app in React. This is already on a webserver and does what it should do. Now I want to develop the frontend myself, which would be no problem if I knew how to edit the code.
On the server I have an index.html, some stuff like favicon and a folder. This folder contains the folders "css", "js" & "media" and I don't understand their content. In the folder "css" are for example the files "main.12345.chunk.css" and "main.12345.chunk.css.map" Both look very cryptic.
Now I found out after some research that this is probably a compressed representation. Possibly compressed with Webpack?
But how can I edit these files in a meaningful way and understand what was coded there in the first place? Normally I would just download the file to be changed with Filezilla and edit it with an editor or Visual Studio code, but in this case I have no idea.
Those "cryptic" files are probably minified. Minification is a process where the original code is minified using several approaches, making it much smaller in size and also sometimes better performing. This is done by Webpack with a build process.
Those files are not meant to be develop with (or even read for that matter). Their sole purpose is to be optimized and be run in a production environment. It's very hard or even impossible to understand those, you would basically have to reverse-engineer them to understand what's going on. Many websites actually use minification for this additional bonus of protection of their application logic, because minimization basically obfuscates client side code. For example, the WhatsApp web client written in React is heavily obfuscated, in order to not allow anyone to write a WhatsApp client (there are efforts for this particular example, but it takes lots of time).
TL;DR: You have to get the original source files in order to edit them.
But how can I edit these files in a meaningful way and understand what was coded there in the first place?
They really are not designed for editing.
Edit the original source code to the application, then run its build script and deploy the output from it.
I am new to the concept of Localizing my react-application. After doing some research online, It seems as if jsLingui is the best library to use and implement translation on my React application. Following tutorials from https://lingui.js.org/tutorials/react.html , everything seems pretty straight forward. but when I run the command
$ lingui extract , I get the error :
module.js:557
throw err;
Error: Cannot find module 'babel-core'
at Function.Module._resolveFilename (module.js:555:15)
at Function.Module._load (module.js:482:25) .....
I have tried re-installing the babel-core , and it shows installed. Even when I check on my file system, I see the folder as node_modules/babel-core .
I also checked my package.json and I see "babel-core": "^6.26.3" as part of my devDependencies. Please any ideas around this will be helpful.
Beside, the pressing question, I also have a few other questions;
1) In the documentation, I am not sure on where to keep .babelrc file created. I hope it is suppose to be inside my babel-core folder.
2) When I was reading on the jslingui library, I discover that, they are still working on something that will help separate translations to be done page by page. I do not know whether this task is completed or still under development because, I am really interested in this one since my application really big and loading the whole translation at all times might become a real issue.
3) What if I have text in one part of my application which is exactly the same as in another part of my application, is it possible to write it in one section and call the id in another part to give me back the information?? or it is out of scope of the library .
4) I am building a social platform therefore I have information coming from the DB, which I do not know the content therefore such information can not be translated using jslingui just as it is. I will like to introduce some translation to this information( similar to what is happening on Facebook). I know this task needs some serious Artificial intelligence in the areas of natural language processing and machine learning. Please, Any good library that I can use to help my application translate only the portions of data provided to it( definitely information coming from DB)??. I have tried googling on this but I got nothing concrete( NB: I do not want Google Translate because, It will help to translate the whole page + names etc) which will mess-up the user experience of my application
jslingui
Thanks
I have tried re-installing the babel-core , and it shows installed. Even when I check on my file system, I see the folder as node_modules/babel-core . I also checked my package.json and I see "babel-core": "^6.26.3" as part of my devDependencies. Please any ideas around this will be helpful.
If you've installed #lingui/cli globally, please remove it and reinstall locally. If you use Babel 7 (your plugins/preset start with #babel/), then you need to install babel-core#^7.0.0-bridge.0 and #babel/core. Both locally as devDependencies. What also helped in some cases is good old turn it off and on again: rm -rf node_modules and reinstall everything...
1) In the documentation, I am not sure on where to keep .babelrc file created. I hope it is suppose to be inside my babel-core folder.
You should keep it in the root of your repository (next to package.json) unless you have specific needs.
2) When I was reading on the jslingui library, I discover that, they are still working on something that will help separate translations to be done page by page. I do not know whether this task is completed or still under development
It's still under development. However, it's a bit different - it helps you create separate message files, but not automatically. That's something we need to solve in further versinons.
3) What if I have text in one part of my application which is exactly the same as in another part of my application, is it possible to write it in one section and call the id in another part to give me back the information?
You have two options. Either you're using generated message IDs:
// App.js
<Trans>Hello World</Trans>
// Component.js uses the same message
<Trans>Hello World</Trans>
In this case, you only need to translate Hello World once, because messages are grouped when collected from source files.
Other option is that you're using custom IDs:
// App.js - define message
<Trans id="msg.hello">Hello World</Trans>
// Component.js - use message
<Trans id="msg.hello" />
4) I am building a social platform therefore I have information coming from the DB, which I do not know the content therefore such information can not be translated using jslingui just as it is. ...
I can't recommend any approach here, but it seems you need to use a machine translation. Either Google Translate or a better one, if you manage to find it. My guess it'll be either low-quality or expensive because as you said, this isn't a trivial task.
I would like to know your opinion about how you would organize the files/directores in a big web application using MVC (backbone for example).
I would make the following ( * ). Please tell me your opinion.
( * )
js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
This is how I've traditionally organized my files. However, I've found that with larger applications it really becomes a pain to keep everything organized, named uniquely, etc. A 'new' way that I've been going about it is organizing my files by feature rather than type. So, for example:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
But, oftentimes there are global "things" that you need, like the "user" or a collection of locations that the user has built. So:
js/application/model/user.js
js/application/collection/location.js
This pattern was suggested to me because then you can work on feature sets, package and deploy them using requirejs with relatively little effort. It also reduces the possibility of dependencies occurring between feature sets, so if you want to remove a feature or update it with brand new code, you can just replace a folder of 'stuff' rather than hunting for every file. Also, in IDE's, it just makes the files you're working on easier to find.
My two cents.
Edit: What about the spec files?
A few thoughts - you'll just have to pick the one that seems most natural to you I think.
You could follow the same 'feature folder' pattern with the spec files. The upside being that all of the specs are in one place. The downside is that now, much like what you're currently doing, you have to places for one feature's files.
You could put the specs in a 'spec' folder of the feature folder. The upside is that you now have actual packages that can be wrapped up in a single zip file with no chance of clobbering other work. It's also easier to find directly related files for writing tests - they're all in the same parent folder. The downside is that now your production code and test code is in the same folder, publishing it (possibly) to the world. Granted you'll probably end up compiling the production javascript down to one file at some point.. so I'm not sure that's much of an issue.
My suggestion - if this is a large application and you figure you're going to have a few hands touching the files, leave something like a 'package.json/yml/xml' file in the folder. In there, list out the production, spec, and any data files you need for testing (you can most likely write a quick shell script to do this for you). Then write out a quick script to look through your source folder for 'package.whateverYouChose' files, get the test files and then build your unit testing page with it. So, let's say you add another package.. run 'updateSpecRunner' or whatever you name the script, and it'll generate you another SpecRunner.html file (or whatever you named the file your running the specs on). Then you can manually test it in a browser, or automate it using phantomjs/rhino.
Does that make sense?
You can find a good example how to organize your application to this link
Backbone Jasmine examples
It looks more or less like your implementation.