Introduction
Embarking on a new professional journey is often accompanied by excitement and high expectations. However, the reality ca...
For further actions, you may consider blocking this person and/or reporting abuse
2: "essential for medium to large-scale projects". Yes if you are using * to import a core library you are asking for trouble in your bundler when used with open source libraries on large projects. Your app might only need certain parts of a library, but asking for * can pull in TONS of code you arent even using. This is bad advice.
Thank you so much for your thoughts! Your concern about using * to import an entire library is especially valid in large projects. ð︸ You are right; It may cause unnecessary bloat and affect the overall performance of the application.
The importance of the "export package" in my articles is more related to ease of import in project components and aims to improve organization and readability. However, I completely agree that caution should be exercised, especially when dealing with open source libraries.
For large projects, selecting only appropriate elements from the library is a best practice for optimization and keeping content lean and efficient. ðYour comments add value and I welcome the opportunity to delve deeper into this area.
But it is not about the import it is about the export. This shouldn't be an issue?
Ahh I see I read it wrong. OK gotcha this is about easily creating a huge index for people to lazily get everything for your libs. But it still begs the question that it's not a good practice when large libraries can dump tons of code to importers who may only want a subset of code. Tree shaking doesn't work when you go to an index file and splat the whole thing.
Typically most libraries put a ton of components in their base export index for ease of importing their exports, possibly using the strategy outlined in #2. From an import perspective I find it best to find the folders where each component is located vs using an index. I've seen cases where one person imports an icon using * and imports a Meg or two of svg icons. I update it to just the icon we need and trim the fat and reduce the bundle size.
Most examples of using libraries use this lazy mode of * at the index of the library to get things done quick with example hello world usages of the libs. When sometimes if the package has a lot of components and moving parts it's best to find the folders for each thing you need and target that one vs importing everything in an index file.
I hate index files after they have screwed my bundle size so many times and I spend hours removing index references to get the specific components the callers of the library needed.
Agree and we can use vscode extensions such as "Import cost" to check how much code is getting imported while using this kind of exports.
I think using named exports to just import necessary part/functions from files exported like this wont be an issue.
@sufian Nice article bro , learned a lot!
Nice article 😊 I definitely agree with some of your points, especially around good naming and directory structure, and configuring aliases for your imports (ie.
@components/SomeComponent😍). However, I do have to disagree with a couple of your suggestions.You should never use an absolute path for your imports. The reason being that the absolute path on one machine is not going to be the same on another one. This may work in a containerized application, but is definitely not a one-size fits all. If relative paths are a problem for your application, I would Highly recommend taking the time to set up aliases as you mentioned in the first suggestion instead of using absolute paths. 🔃
Barrel files cause lots of problems. Build performance issues, bundle size impacts, breaking of Intellisense and autocompletion, and all the hassle they can cause with Typescript (if you're using it). I can't tell you how many hours I've spent trying to fix circular dependencies that were caused by barrel files! Barrels are for aging wine and whiskey, please don't use them for code! 🥃🍷
To end on a positive note, I 100% agree with #5! Properly formatted and standardized code matters so much. It's so hard to work on a project that lacks the use of tools like these. So great point here!
Thanks for the article and starting some great conversation on the topic of best practices!
I think for absolute paths he ment @ rule paths provided by TS which will be resolved while compiling by TS and for a project paths starting from SRC will always going to be same in all machines for same project
when he says absolute path
He means this -> "src/component/home.ts"
He doesn't mean this -> "D:/work/react-projects/my-test-project/src/component/home.ts"
I can certainly see what the author meant to convey here as you describe. However, the term "absolute path" has a very specific meaning:
What you and the author are referring to actually has different names depending on the tool you're using.
In Next.js, these are called Absolute Imports.
In Svelte, these are called Aliases.
They are also called Aliases in Nuxt.js
I hope this adds some clarity to my origin comment 😃
Great article! It provides valuable insights for React developers, especially beginners, covering essential practices for writing clean, maintainable, and collaborative code. Just wondering if it could have gone a bit deeper into potential challenges or alternative strategies related to the "export barrel" technique.
Thank you so much for the positive feedback! I'm thrilled to hear that you found the article valuable, especially for React developers, and I appreciate your suggestion for diving deeper into potential challenges and alternative strategies related to the "export barrel" technique. 🚀
I disagree with #2 and #3. After having used barrel files and default exports regularly, I’ve decided they are mostly anti-patterns. I would prefer explicit imports of module paths and named exports given the option.
After taking a closer look at #3 I see you are advocating for named exports over defaults 👍.
Just a heads up that you can add highlighting to the code blocks if you'd like. Just change:
... to specify the language:
More details in our editor guide! Awesome post!
Yep, I was going to suggest the same.
Does everybody prefer
barrel? In my case, sometimes barrel makes me confused where the component is being imported. And I ended up importing the whole other components when I needed only one component. This slows down the test.I totally get your point, and you're not alone in feeling that way about "export barrel" techniques. It's true that personal preferences and project requirements can play a significant role in choosing the right approach.
The potential confusion you mentioned about where a component is being imported is a valid concern. It's crucial to strike a balance between the convenience of streamlined imports and the potential downsides, like accidentally importing more than needed and impacting test performance.
I could be wrong but doesn't #2 inflate the bundle size? I think each exported file is included in your chunk when building the app. This happened to us with Gatsby SSG
Seeing others comment about #2, and here is a thorough explanation on why this is something to avoid for the time being:
marvinh.dev/blog/speeding-up-javas...
Thanks for sharing your tips to improve in React! ❤️
You're very welcome! ❤️ I'm glad you found the tips helpful
Nice article, thanks for sharing it!
You're welcome! 😊 I'm thrilled that you enjoyed the article.
Louder!
Fantastic post! Thanks for sharing!
You're welcome! 😊 I'm thrilled that you enjoyed the article.
Thank you for these highlights!
You're very welcome! ❤️ I'm glad you found the tips helpful.
Nice