Better way to import files for webpack bundle size - javascript

hooks/index.js
export { default as useDialog } from './useDialog'
export { default as useCurrencies } from './useCurrencies'
export { default as useUser } from './useUser'
Let's imagine that I have 3 files in hooks folder (useDialog, useCurrencies, useUser) . I want to make the correct imports from this folder. Now I do imports like this :
import {useDialog} from 'hooks'
Is it correct way to import this file , or it is better to import it like import useDialog from 'hooks/useDialog' ? What is better for my bundle size ?

You can try yourself and compare the bundle sizes on production from before and after. I'm gonna explain how to do it if anyone needs it.
First do these steps with the code importing from the index: import {useDialog} from 'hooks'
yarn build
serve -s build
Open the local address (http://localhost:5000/) on incognito mode. Then open Inspect -> Coverage.
At the bottom you can see the size. e.g: 1.2MB of 2.1MB (55%) used so far 964kB unused
Then change your code and import directly from the file: import useDialog from 'hooks/useDialog', and repeat the build and check the size.
Maybe if the files are too small you are not going to notice a difference, but you will if there are any big files or files that imports a big external library.
I tried this comparison on my project and there was one file importing and using moment. I was not even using this component, but the bundle size was increased because I was importing another component from the same index.
Before I was always importing from a folder like 'hooks', but from now on I will always import directly from the file 'hooks/useDialog'.
I'm just sharing my experience! Please, compare the bundles on your own projects!

Related

Best practice for importing component from components library in React.js

When I create components in React, they're all in a folder called component and each component has a dedicated folder with the same name as the component itself, e.g. ../components/Input.
But a big concern is about naming files. In order to avoid having to long paths, I name the component inside the folder Index.tsx so that when I import, I'll only have ../components/Input otherwise, it would be a very ugly import path like ../components/Input/Input.
So, by naming Index.tsx, in my IDE, I end up having too much index files open and then I get lost.
So what I did was to rename all those components file with the same name as the folder Input.tsx and exporting them using named export like export const Input:React.FC<InputProps>=(props)=>{...}, then at the root of my component folder, I created one index.tsx file where I export all those components so that while importing them in my pages, I can just write import {Input} from "../components".
I like this approach, but my next concern is about tree shaking. Because I don't want to import every time the entire components library.
So with the above approach, does React handle automatically tree shaking for us?
There's a tweet about the possible issues related to re-exporting everything with index files.
If your project has a components/index.js file which re-exports all your components (and does nothing else), that’s one example.
This is bad for performance – for two reasons.
It makes code splitting ineffective.
When you do
import { Button } from './components'
you’re importing not only Button but the whole ‘./components’ file. Which means you’re bundling the whole file – with all the components it exports.
It makes bundle initialization more expensive.
Every time a browser downloads the bundle, it has to execute it – and all its modules as well. If there’re a lot of modules, or some of them do something expensive, this can take a while.
Someone else suggests configuring webpack's sideEffects option so that the tree-shaking can still optimize the bundle as much as possible.
What I'm suggesting is to create small component modules inside the components directory.
- components/
- Input/ # component module
- index.ts # exports public API
- Input.tsx # actual component implementation
- Input.test.tsx
- Input.scss
- Input.stories.tsx
- etc.
Where the index.ts only re-export the public API for this component.
// index.ts
export { Input } from './Input';
export type { InputProps } from './Input';
// etc.
So that we have non-repeating paths when importing, but the filename we're actually working with is named according to the component.

Webpack won't treeshake unused named export objects (using Create React App)

Small repo which showcases the issue: https://github.com/Huuums/repro-webpack-treeshaking-object-issue
I have a customIcons.jsx file which exports a few SVG paths (some of which I may or may not want to use at some point). I export only 2 of the 4 icons into App.js (in above example).
import { abacus, addressBook } from './customIcons';
However when I now run yarn build the bundle size is as big as if I imported all 4 icons. It does not change at all depending on how many icons I import into App.js. Only when I omit the whole import statement (not importing anything from the file) I can see that the bundle size of the main.[hash].chunk.js decreases.
Am I doing something wrong here that webpack does not treeshake the unused objects?
https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free
Turns out you have to mark your package as "sideEffectfree" for treeshaking to take place.
Setting "sideEffects": false inside the package.json the issue.

Vuejs, import component file issues

I have a files structure issue that I am trying to fix when referencing components into other components as imports.
The current files setup I have looks like this...
I am working on the file called security_passphrase.vue and within that file I reference 2 files to import as I need to use them there.
import dropdown from '../components/vue_form/dropdown.vue'
import formbutton from '../components/vue_form/form_button.vue'
The compiler cannot find the modules I am trying to load.
Error: Cannot find module '../../components/vue_form/dropdown.vue' from 'C:\wamp64\www\merchant-backend-new\merchant-backend\resources\assets\js\components\vue_form\concertina_form'
Error: Cannot find module '../../components/vue_form/form_button.vue'
from
'C:\wamp64\www\merchant-backend-new\merchant-backend\resources\assets\js\components\vue_form\concertina_form'
I have tried different ways to make this work but no success. The files I am trying to import are outside of the folder where the file is I am working with.
/concertina_form/security_passphrase.vue /vue_form/form_button.vue
/vue_form/dropdown.vue
Help will be great :)
import dropdown from '../dropdown.vue'
import formbutton from '../form_button.vue'
Should be the correct way to import these files, using ../ goes down one directory which will take you from the concertina_form directory to the vue_form directory.

Why do named imports cause slower builds and larger output?

I was looking at the material-ui documentation and saw the below comment about how to properly do an import in ES6.
What is the technical reason that doing a named import is slower and causes larger output?
Notice that in the above example, we used:
import RaisedButton from 'material-ui/RaisedButton';
instead of
import {RaisedButton} from 'material-ui';
This will make your build process faster and your build output smaller. For a complete mapping of Material-UI components to import, see /index.js inside the Material-UI npm package root directory.
That's not exactly enough context to see what's happening.
There are two separate things going on.
Default exports are typically going to be bigger than property exports.
export default ObjectWithAllKindsOfStuff {}
export function someFunction () { }
The second one is going to be smaller, practically 100% of the time, if they're in the same file.
Importing a single function from #angular/core is going to require opening a whole lot more files (taking longer) than importing everything from #angular/a/b/c/d/e/f.js.
If you are in the root folder's index.js, and you export * from './a', and in there, you export * from './b', et cetera... then for WebPack or Rollup or whatever, it has to load all of the files below, to figure out what each one exports, so it can tell where the function actually lives.
Their example is actually unfair, in that using the import { x } from 'package/SubPackage/SubSubPackage'; is going to be even smaller than import All from 'package/SubPackage/SubSubPackage';, but if you import { x } from 'pacakge'; and it has to go all the way through every folder, spidering through all of the exports, to figure out which file the function comes from, that's the comparison they're really making - it has nothing to do with the export {property} from versus export Namespace from if they're both talking about the same file, in the same subfolder.

react, webpack: avoid ".." in import statements

I'm currently learning react and thus es6/es7 and webpack.
Coming from a largely python background I'm annoyed by the folder sensitive path declarations for import statements, i.e. the use of ../../ in import statements. This means if I move a file to a different directory, i need to change the import statements declared in the file.
Python's import statement doesn't have this issue. I'd like to mimic that behavior
(search first a particular directory for this path, if not search this other base directory)
e.g. if i have the directory structure
myApp
components
component1.jsx
stores
store1.jsx
views
view1.jsx
node_modules
react
etc
in my view1.jsx I don't want to write
import Component1 from '../components/component1'
I want to write
import Component1 from 'components/component1'
or maybe even
import Component1 from 'myApp/components/component1'
just to make sure I don't have name collisions with some npm package I may be using.
What is the correct way of accomplishing this in webpack? Is it using alias?
I ended up following #zerkms recommendation. resolve.modulesDirectories is the way to go.
I wrote a loader to accomplish this, https://www.npmjs.com/package/future-require-loader. It will autoload a path anywhere three underscores surround a partial file path ___filename.js___. it also allows folder paths: ___folder/filename.js___. it will attempt to match the first file path that includes the string so you will want to include folders if there could be a conflict.

Categories

Resources