What methods or tools do you use to reuse components/parts of your previous projects? Do you reuse components in most of your projects or just in some specific area like web development?
It just feels as such a hassle and overkill to maintain another repo/package just for a few components.
Another problem is that usually, I realize I want to change the basic component while I'm using it in a different project. So now I have to open another workspace, update it, and publish. Then `npm update` in the project where I'm using my component...
I just feel it should be much easier.
Git submodules might be worth considering. It’s like having the dependency copy pasted into your project so you can modify it. Different projects can pin to different versions of the submodule.
There are a number of options that allow you to store React (or any really) type boilerplate in a git gist and then access it via VSCode if that is what you're thinking of. Often via a VSCode extension.
For React projects I have a "super-set" of components based on material-ui. Small stuff that I find myself reusing and helper functions for validating/formatting.
I keep them in private github repos and gists, i won't probably ever publish them since its a different "quality-standard" for documentation and code quality than doing something for myself.
Up until a year ago or so I used to extract often-used components (I was mostly doing Android and Java/Kotlin stuff back then) into seperate libraries that I then included everywhere locally (because publishing to Maven was a huge hassle). Then I realized this was a problem both in terms of versioning (breaking changes) and for collaborators who had to set up the extra library exactly like I did on their system.
Nowadays I still copy code sometimes or re-use binaries if the builds are reproducible and I can safely streamline them but I don't try to properly extract anything anymore.
Depends on the component. Have a favorite circular list I've used 100 times. Had a video rendering library I used for multiple embedded display devices.
https://wordsandbuttons.online started as an experiment in unchitecture. Every page is a copy-paste of previous pages. On the plus side: no dependencies, every page is self-sufficient, and the code evolves freely from page to page.
On the downside, it's impossible to maintain it without automation. If I want to change something in several copies, I have to write a script to do this for me.
As soon as I use the same code twice, I try to make it into a generic component. The same logic twice becomes a function. The same concept twice becomes a package in a shared library.
Emphasis on "try": Some languages make it difficult to avoid code duplication in certain situations. (Looking at you, Go...) I allow code duplication if it's more readable than trying as hard as possible to refactor out common parts.
For Go-based API-driven services, we have collected some of these reusable modules and functions at https://github.com/sapcc/go-bits.
The thing I've never understood about this is how to track 3 times. I can remember something twice, but the third time, I'm drastically less likely to realize it.
Also, this seriously breaks down when multiple developers are working in the same area.
Reusable components of any nontrivial complexity are, for the most part, a pipedream. Unless you have a dedicated team maintaining and extending them, it immediately becomes more of a hassle than anything. Documentation is slim, edge cases aren't completely thought through, and configuration is never sufficient. Visual design patterns can absolutely be standardized. But the actual implementation as we all know changes ever so slightly from project to project in ways that can almost never be forseen. I'm all for component driven UI architectures, but the idea of being able to reuse anything complex between projects and teams has never really worked out in my experience unless it is a highly active open source project, or something you built yourself and fully understand.
I have a junior developer who is hellbent on extracting little chunks of things to be “reused” on future projects but we work at a marketing agency that does a lot of bespoke design.
Sure, sites might have a collapsible FAQ section, but when the design is so wildly different from project to project, it takes more time to overwrite things than to start from scratch and write the 3 lines of jquery to get the section to toggle open and close.
I totally understand component driven UIs but marketing outside of generic landing pages is not a productive area to spend your time creating abstractions.
Yes, definitely. Not as consistently as I'd like to, but I definitely do. I mostly work on the JVM platform, and use Maven or Maven compatible build tools, so I tend to split shared code out into independent projects at some point, and push them to a private Artifactory instance, and then depend on them just like any other 3rd party dependency.
To the extent that I do any work in other languages (Javascript, etc.) I do less of this because I'm less familiar with the tooling that is analogous to Maven/Artifactory.
I've lost count how many times I've implemented Google Tag Manager or Google's product feed on the ecommerce sites I build and maintain. Sometimes its a standard install (I should get around to building a collection of libraries for stuff like this). Othertimes it's a totally customized bespoke setup that tracks things down to individual clicks on every page (a good flag that the client is on its last legs).
Similarly, for those sites, I have a collection of Python scripts that translate between CSV and the standardized XML imports that the ecommerce platform uses (SFCC). I almost certainly have to modify it a bit for different heading names, but it works pretty well.
When I use Java and need to search through XML, I built a class that searches for a specified child element, because the NodeList class isn't iterable (can't be used in a for each).
I make (web app) components with only minimal regard for cross project reusability. I don't add any features to them that I don't need for the current project, but I do try to keep them small and decoupled.
I find that liberal use of copy-paste _across projects_ is way cheaper than building up a library of well thought out, generic components even in the long term.
If you have ten concurrent projects that need the same components at the same time it could make sense to build them up as privately published libraries. Otherwise it's unlikely that the overhead and rigidity of that approach will pay off if you only have one or two projects that you're actively working on at any given time.
Code reuse is a powerful feeling of productivity in programming, however in many cases the pains outweigh the gains.
After making several npm packages, I've learnt that you need to put yourself in another frame of mind to reuse code. Here's some concrete steps in order to create good reusable components.
0. Ask yourself if this is this worth the overhead of code reuse???
1. Think from the perspective of the user of the component (because you will be the user in most cases), what's the most logical way to use and customise this thing?
2. Simplify the getting started as much as possible, it's much harder to reuse if it's complex to add to a project.
3. Remove as many dependencies as possible, this makes it simpler, lighter weight and allows more options for users of the package, (they can use different versions etc..).
4. Try to make an MVP and iterate on it.
5. Strive for backwards compatibility where ever possible.
There's probably many more good points I'm missing, but that's a few that I think are important.
Identify when you're solving a problem that isn't a one off.
Solve it in a way that also works for the other situations you expect it is needed (i.e. make absolutely everything that's unique to this first implementation a configuration item outside the unit or callable via an abstraction/extra interface from the specific use). This is easier to do if designing something for multiple places at once.
i.e. Make it modular from the start. This requires more work up-front.
I work in embedded so we reuse: device drivers, MCU abstraction layers, communication protocols, key (to our business) areas of application level logic.
Reusing components is about reusing design, which ultimately means you're reusing/extending a specification as well. If up front you can define the specification to be standard for a bunch of projects you can plan for a lot of reuse and justify the upfront work.
27 comments
[ 2.8 ms ] story [ 59.9 ms ] threadI would make use of a tool where I could "store" such components.
Another problem is that usually, I realize I want to change the basic component while I'm using it in a different project. So now I have to open another workspace, update it, and publish. Then `npm update` in the project where I'm using my component... I just feel it should be much easier.
I keep them in private github repos and gists, i won't probably ever publish them since its a different "quality-standard" for documentation and code quality than doing something for myself.
Nowadays I still copy code sometimes or re-use binaries if the builds are reproducible and I can safely streamline them but I don't try to properly extract anything anymore.
https://bit.dev/
On the downside, it's impossible to maintain it without automation. If I want to change something in several copies, I have to write a script to do this for me.
I use it on daily basis for storing my code snippets.
Emphasis on "try": Some languages make it difficult to avoid code duplication in certain situations. (Looking at you, Go...) I allow code duplication if it's more readable than trying as hard as possible to refactor out common parts.
For Go-based API-driven services, we have collected some of these reusable modules and functions at https://github.com/sapcc/go-bits.
Also, this seriously breaks down when multiple developers are working in the same area.
I have a junior developer who is hellbent on extracting little chunks of things to be “reused” on future projects but we work at a marketing agency that does a lot of bespoke design.
Sure, sites might have a collapsible FAQ section, but when the design is so wildly different from project to project, it takes more time to overwrite things than to start from scratch and write the 3 lines of jquery to get the section to toggle open and close.
I totally understand component driven UIs but marketing outside of generic landing pages is not a productive area to spend your time creating abstractions.
To the extent that I do any work in other languages (Javascript, etc.) I do less of this because I'm less familiar with the tooling that is analogous to Maven/Artifactory.
Web devs like to release generic reusable parts as open source. Often in the hope that someone else will help maintain them.
Whereas finance and game development like to keep custom tools and libraries that may give them an advantage in house.
I've lost count how many times I've implemented Google Tag Manager or Google's product feed on the ecommerce sites I build and maintain. Sometimes its a standard install (I should get around to building a collection of libraries for stuff like this). Othertimes it's a totally customized bespoke setup that tracks things down to individual clicks on every page (a good flag that the client is on its last legs).
Similarly, for those sites, I have a collection of Python scripts that translate between CSV and the standardized XML imports that the ecommerce platform uses (SFCC). I almost certainly have to modify it a bit for different heading names, but it works pretty well.
When I use Java and need to search through XML, I built a class that searches for a specified child element, because the NodeList class isn't iterable (can't be used in a for each).
I find that liberal use of copy-paste _across projects_ is way cheaper than building up a library of well thought out, generic components even in the long term.
If you have ten concurrent projects that need the same components at the same time it could make sense to build them up as privately published libraries. Otherwise it's unlikely that the overhead and rigidity of that approach will pay off if you only have one or two projects that you're actively working on at any given time.
After making several npm packages, I've learnt that you need to put yourself in another frame of mind to reuse code. Here's some concrete steps in order to create good reusable components.
0. Ask yourself if this is this worth the overhead of code reuse???
1. Think from the perspective of the user of the component (because you will be the user in most cases), what's the most logical way to use and customise this thing?
2. Simplify the getting started as much as possible, it's much harder to reuse if it's complex to add to a project.
3. Remove as many dependencies as possible, this makes it simpler, lighter weight and allows more options for users of the package, (they can use different versions etc..).
4. Try to make an MVP and iterate on it.
5. Strive for backwards compatibility where ever possible.
There's probably many more good points I'm missing, but that's a few that I think are important.
I follow a rule of 3, if I have to do something at least 3 times, I refactor the code into a reusable component.
I work in embedded so we reuse: device drivers, MCU abstraction layers, communication protocols, key (to our business) areas of application level logic.
Reusing components is about reusing design, which ultimately means you're reusing/extending a specification as well. If up front you can define the specification to be standard for a bunch of projects you can plan for a lot of reuse and justify the upfront work.