My team work on a multi page website and so far we used JS and some angularjs.
We thought to give a try to Reactjs so we added one page written in jsx and we also used webpack for the bundling (compiled by babel).
Now that we have that one page we want to expand our work with Reactjs. The first thing we have in mind is to split that (rather long) file. What does it actually means? We defined some components in it and for the first step we want to take each one of them to an individual file. My question is regarding to Webpack's entry section. I couldn't find any better approach than to add each and every file written in jsx explicitly to the entry section. It is even described in Wepback documentation: https://webpack.js.org/concepts/entry-points/#multi-page-application
Is it really the only way to do that?
In a few weeks I expect us to have at least 50 files containing pages, components and other stuff. Does a webpack file in a big project contains all the files explicitly?
Thanks.
You don't need to add every jsx file to the entry section. You only need to add your entry point.
For the component you are building, you probably have the main component (the very top, e.g., App.js) importing or requiring other (sub)components. You only need to add the top-level or main component to the entry section.
The main job that webpack does is traverse down the module graph (each import or require) and roll everything up into a bundle based on the top-level component (usually the whole app).
use imports and exports in your js files and have 1 main file that webpack looks at
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
When, we use create-react-app while creating a new react application. It creates multiple files. Out of which index.html is the rendered html application, where multiple jsx elements are placed depending upon the react application App.jsx
I was curious on what is the best way to import google fonts, bootstrap, jquery and other different external plugins?
As I have researched there are two ways of importing external modules. For eg. if we consider bootstrap that is to be imported from cdn: https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js
Then, one way to import is place it in public/index.html:
# Rest of the index.html code
<div id="root"></div>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js"></script>
# Rest of the index.html code
Other way is to install bootstrap using npm i bootstrap#4.3.1 --save, and then put it as import in src/index.js .
The above thing can be applied to multiple places. Say, we have to import popper.min.js or jquery.js or import css fonts. Which is better? Placing it in index.html or inside index.js?
Also, what is the major difference between placing it at the two different places?
Both approaches will have the similar effect of making that library available to your application.
The HTML approach causes your dependencies to be fetched and executed at run-time by the browser. Much like you'd include imgs on a page, you can include scripts on a page with the source of the script either inline or from another URI. So, let's say you create an HTML page, put a number of script tags around it, and then hit that page in your browser. Your browser will scan the HTML page, identify all script tags and start downloading them. It will also remember in which order the script tags were found, and it will parse and execute them in that order (unless you use async and defer attributes on them).
Ok, so, browser sees HTML page consisting of various elements, including some script tags, download them (probably in parallel), and execute them (sequentially). Now, these scripts may or may not know anything about each other on the page.
Now, let's go to the realm of React and other rich Javascript apps, which depend on various Javascript libraries.
When you do Javascript Module Bundling i.e. import { something } from "package", this will get picked up at compile time by your Javascript compiler, e.g. React via create-react-app when you do npm run build, or Angular's equivalent script, or other compilers such as webpack, etc. These compilers will scan not just a single file, but rather your entire application. They typically start from an entry point, e.g. index.jsx, and then discover the graph of dependencies and recursively go through each file or module that they identify and discover those dependencies and so on and so forth. Once the compiler is done discovering, resolving, building, and bundling your app, you'll typically end up with a single Javascript file (e.g. main.[some hash].js) which is your application AND all dependencies (all those other modules you imported) bundled together in a single file.
So, you see the big distinction is:
HTML scripts are independent resources that are downloaded and processed by the browser at run time.
Javascript modules are discovered at compile time and end up being bundled together with your application code in a single file.
I'm leaving aside concepts such as package splitting and dynamic references, etc. in order to illustrate the larger distinction; you'll end up reading about variations in each approach as you dig further into them.
HTML Script advantages:
They are fetched independently, perhaps from a CDN, may even already be cached in your browser if another website needed them and downloaded them previously. So things like jQuery, loDash, etc. are common packages that may have already been downloaded, and your browser will benefit from its internal cache.
They can be downloaded in parallel; although you can rely on the browser to ensure that they get executed sequentially. So for example if you had your own script that relied on jQuery having already been loaded, all you need to do is to <script src="jquery.min.js" /> first and then <script src="myscript.js"> and that sequence will be respected.
Javascript Module Advantages
Your code may not need the entire jQuery, lodash, or whatever other library that you're referencing. By importing whatever function of your dependencies that you need in your source code, a smart compiler might be able to artfully scalpel only those functions out of the larger library (tree-shake the library), and you'll end up with a smaller overall download payload.
Your entire bundle can be minified, yielding an optimized package.
Your entire bundle will be (/can be) in a single file. One download, and your entire app is loaded and ready to use. No need to worry about downloading various resources from various URLs.
Hybrid Approach is OK
Feel free to use a hybrid solution! If you inspect your compiled React code, you'll see that the create-react-app compiler will inject a <script src="static/js/main.js" /> element at the end of your HTML document. This means that your app can rely on other`s included higher up in your HTML document. So, feel free to load up some libraries in HTML and reference other ones through JS modules. In fact, there are cases that you'd want to do this; for example, including the Google Maps script can be easily done via an HTML script directive, and your React app can still use the GMaps library.
I've created a web page that's for all intents and purposes, a style guide for other developers working on our application.
I have my .scss files within the _sass directory in my Jekyll project, and it's created all the CSS files beautifully. On my page however I want to display the code from these .scss files in the page within some <pre><code> tags.
Currently I have the code in here repeated in both places. When it was quite small it wasn't such a problem, but now it's got bigger it needs DRY-ing out.
I first went down the path of using Jekyll's {% include [path/to/file] %}, and then realised that only works for stuff in the _includes folder, and I couldn't use the include_relative option either as the _sass folder isn't a child of the location it's used.
Secondly I tried using the angular approach, as I'm already using it in my application. Threw in some <pre><code ng-include="'../_sass/components/_sflButton.scss'"> and expected it to work. Of course, it didn't because the _sass folder isn't generated into the actual site when you run it. And I can't seem to find a way of getting it to include it. Tried changing a few things in _config.yml to no avail.
So, TL;DR, I want to either be able to include the code from my _sass folder onto my page via Jekyll, or find a way of getting the _sass folder to be loaded into the generated site so I can load it in with Angular. Am I trying to do an impossible task here? Willing to listen to any suggestions that mean the code is only written in one place.
The theory behind getting this done is as follows:
_sass is a special directory for Jekyll (similar to _layouts, _includes) that is handled differently in comparison to other directories you create. Its contents are not output to the destination directory.
you can write simple ruby programs and add them to a directory called _plugins and Jekyll will run those custom programs during the build process. (Ignored by GitHub Pages).
Now write a ruby program to "read" the contents of _sass and have the resulting data be formatted as a hash and have this hash fed to existing site_payload
The hash can be additionally passed as a Drop instance to have the data available via the Liquid templates.
I concede this answer doesn't actually solve your problem esp., if you're not familiar with Ruby, and Jekyll codebase. but it'll serve as a starting point..
I am building a reactjs application using gulp and Browserify. I have used material-ui components in my application. There are 8 pages in my application using different components.
The build.js created by Browserify is 4mb in size. I want to reduce its size. I have searched and learned a little about the lazy loading design pattern. But I am confused how it should be used to make the size smaller of my application?
I am also using react router in my application so there are 8 routes defined. I have an idea that we can lazy load the files required for each route, but how could that be done in react?
P.S : I would have loved to share some code, but i don't understand what kind of code will be required for such a question.
The problem is most likely that your javascript contains source maps. Source maps can easily increase the size of your code by an order of magnitude. Try taking a look at your compiled JS file and if you see large random strings that look something like this:
dlfheihfgrewifjwe;iofgrewfwejroifnekw.nfoeiquf0eqf;oiwehjfkl;qwejfio;qeo;f;qoihfi;qejhfkjqwehj
then you are including source maps in your compiled Js.
Check your browserify config to make sure that you are not compiling with source maps.
I want to know what're the drawbacks of declaring and using ONLLY ONE module in my SPA?
Does it reduce testability?
Does it impact the performance?
Does it make code less readable or maintainable?
assuming that:
It is single page application
I don't share any block of code to another application
I use browserify to pack all files into one big .js file.
Even if I don't pack all js into one bundle file, isn't it true that all sub-mobules will be eventually depended by the root module? And therefore downloaded from server at the very beginning?