I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Having an index barrel with all available exports can be very useful for readability and makes it easier to move/rename the implementation files. (Think __init__.py indexes in python.) It also allows for implicit private exports which can be more easily respected by a module consumer.
That said, export * from 'foo' introduces magic that may in fact produce more opaque code instead. Prefer explicitly exporting the relevant symbols as an actual index.
I do believe the barrel pattern is useful in some cases. Like say, an API interface, so you can call the APIs with something like api.user.get, so user gets autocomplete on the APIs can narrow down from there. But putting interfaces/components there in the same name can get confusing real quick. With editors like VS Code that support automatic imports, all users would see two imports for this and then might end up picking the wrong one making the barrels kinda useless.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You should also add - don't do that ;)
Hi! What did you mean?
Tell me why I should maintain one + file for every directory and what is an issue to import file directly? And who puts one interface per file?
Probably more prevalent in declarative styles of codebase? I would see one or more varients in one file. But not just one interface.
Sorta. Don't do that... with a blanket export.
Having an index barrel with all available exports can be very useful for readability and makes it easier to move/rename the implementation files. (Think
__init__.py
indexes in python.) It also allows for implicit private exports which can be more easily respected by a module consumer.That said,
export * from 'foo'
introduces magic that may in fact produce more opaque code instead. Prefer explicitly exporting the relevant symbols as an actual index.I do believe the barrel pattern is useful in some cases. Like say, an API interface, so you can call the APIs with something like
api.user.get
, so user gets autocomplete on the APIs can narrow down from there. But putting interfaces/components there in the same name can get confusing real quick. With editors like VS Code that support automatic imports, all users would see two imports for this and then might end up picking the wrong one making the barrels kinda useless.