Re-export (certain) library components from barrel file

Question

Situation

At the project I'm currently working on we're using Chakra UI to create our UI. But I guess this question applies to whatever (UI) library you're using.

There are certain components that need to be customized and so we're creating our own components where we wrap the chakra ui component. Also, some components are compound components.

So, <Menu> should be used with <MenuList> and <MenuItem>. Now let's say we have to create our own version of the <MenuItem> component.

Now, when we want to create a menu we have to import 2/3 of the components from @chakra-ui and only one from our own directory.

To make life simpler we have a barrel file (index.ts) in the root of our components directory. So the <MenuItem> component, located at src/components/menu/MenuItem.tsx, can be imported from @components.

Now the question is: Does it make sense to re-export the Chakra components from src/components/index.ts so we don't have to worry about 'picking the right location to import from'.

The way I see it the pros of re-exporting are:

• No need to figure out where to import from. Need a component? -> import from @components
• Decide later to customize a chakra component? No need to replace the import statement everywhere

And a con I can think of is:

• The index.ts in components isn't really 'pure', because it does more than exporting our own components.

I couldn't find anything on Google that spoke about this specific issue and I feel like I'm maybe missing something.

Answer 1

As with a lot of things, it is a cost-benefit analysis that you need to make.

As I see it, the costs of re-exporting are:

• The index.ts in components isn't 'pure' as you said
• It is harder to determine if you are using a stock component or a customized one (you can't see it in the file that uses the component)

The benefits are:

• You don't have to check for each component if you should import the stock one or if there is a customized version
• You can more easily apply a new customization globally

For not re-exporting, the costs and benefits are reversed.

You and your team now have to decide what weighs more heavily for you and that also depends on how much customization you do and how often global customizations are applied after components are already widely used.