Con­tent changes


You con­stantly need to be aware of con­tent changes that you need to make. Just be­cause you are reusing a com­po­nent, it doesn’t mean con­tent is go­ing to be the same. If you were build­ing out a web­site and wanted to use the same re­us­able but­ton, then the text of the but­ton is go­ing to be dif­fer­ent. It might not mat­ter so much for smaller changes but it can get tricky when chang­ing things on a larger scale, even if they hap­pen to share the same func­tion­al­ity.

If you look at Net­flix as an ex­am­ple, when you se­lect a movie it takes you to a sep­a­rate UI screen where the in­for­ma­tion for that movie is dis­played. This is ex­actly the same UI ev­ery time; the only thing that changes each time is the ac­tual con­tent.


When it comes to styling, you might have sep­a­rate style fold­ers inside your com­po­nent folder. This would con­tain the styles for each com­pany that you are build­ing for. • styles - com­pany 1

- com­pany 2 - com­pany 3

Of course, this is only most likely to ap­ply if you have sev­eral web­sites for one brand. If you were build­ing out a brand new web­site, then you would only need one set of styles. Try to keep this ap­proach con­sis­tent for each project you build out, that way you only need to change the styles them­selves rather than the class types.

Shar­ing your com­po­nent

The best way for ap­pli­ca­tions to in­stall your com­po­nents is through NPM, so make sure they’re all pub­lished there and are all ver­sioned – ma­jor, mi­nor, etc. All fu­ture projects that want to use the com­po­nent can run npm in­stall.

Be­fore pub­lish­ing, make sure you go to your com­po­nent folder and check that pack­age.json is up to date, with at­tributes like name, de­scrip­tion and au­thor. Re­mem­ber that you are go­ing to need to create an ac­count if you don’t have one al­ready. You can do this at http://npmjs.

com/. En­sure that you keep your NPM reg­istry pri­vate!

Then all you need to do is log in, en­ter your user­name and pass­word and fi­nally pub­lish us­ing the fol­low­ing com­mands:

npm lo­gin npm pub­lish

Con­tin­u­ous in­te­gra­tion server

Set­ting up a con­tin­u­ous in­te­gra­tion server (CI) is cru­cial when it comes to us­ing com­po­nents across mul­ti­ple ap­pli­ca­tions. This is to make sure you don’t break any ex­ist­ing ap­pli­ca­tions. You can use CI to run your tests and create au­to­mated builds. CI builds your app the mo­ment you com­mit and makes sure it runs on an­other ma­chine.

Tech­nol­ogy chal­lenges

One chal­lenge is that there are al­ways go­ing to be new li­braries and tech­nolo­gies. How are you meant to in­no­vate when ev­ery­one is us­ing the same thing? A carousel that is de­vel­oped in 2018 might be com­pletely dif­fer­ent in 2020 and there might be bet­ter ways of show­cas­ing your prod­ucts. You have to ac­cept that there is al­ways go­ing to be change; as a de­vel­oper you need to be able to know what’s com­ing and plan ac­cord­ingly. You can al­ways build out a sep­a­rate com­po­nent later down the line or even build upon the ex­ist­ing com­po­nent. Re­mem­ber that it’s eas­ier to tackle com­po­nent by com­po­nent, rather than all at once.


You may ex­pe­ri­ence con­flicts when it comes to ver­sion­ing. If you go with Re­act, make sure your com­pany is on the same page. De­cide what ver­sion of Re­act you want to use (that’s if you de­cide to use Re­act). Hav­ing your own starter kit can re­ally help the process along.


Some­times one of the big­gest chal­lenges is dis­cov­er­abil­ity, es­pe­cially in larger or­gan­i­sa­tions with sep­a­rate de­vel­op­ment teams. Your de­vel­op­ers may not find what they are look­ing for or be un­sure whether or not the com­po­nent works ex­actly how they need. This can lead to them build­ing out some­thing new for them­selves, which then in­volves more time and money.

A great way to avoid this is to have an ex­ter­nal tool that show­cases the com­po­nent us­ing demos and screen­shots. A good ex­am­ple of this is Elec­trode Explorer, which you can read more about here: https://www.elec­ html#elec­trode-tools.


If you are only now think­ing about reusing code, then it might take some time to get the struc­ture in place. You have to con­sider how you think reusabil­ity would suit your busi­ness in the fu­ture. Can you train and re­struc­ture your cur­rent work­force and how long will it take? In the long run, it is likely to pay off and save you both time and money whether you are an agency or an or­gan­i­sa­tion with a chain of web­sites.

Just be­cause you are reusing a com­po­nent, it doesn’t mean con­tent is go­ing to be the same

Above Elec­trode Explorer en­ables you to au­to­mat­i­cally run a demo of each com­po­nent, so that you can get a bet­ter idea of how it might in­te­grate

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.