Many of our Development blog posts spring from troubleshooting issues we uncover as we solve challenges for our customers. Here’s one…
Setting the Stage
Let’s assume you have an org where you have created 50 Lightning Components, and named them as follows:
You tested and everything is working, but business decides they want to change the name of all these Lightning Components.
If you have been in Salesforce development, renaming classes or triggers or Visualforce, you are already aware of metadata API, and ANT or JSForce. You immediately download all the Apex classes and triggers, rename them manually, change the names in package.xml, deploy and then probably use destructive xml to destroy old files. Doesn’t sound fun, right? However, the structure of the files is manageable (every class, page or trigger is just one file) and hence no big deal. If I’m doing such tasks, I’ll tune into music or a podcast to kill some boredom.
Now, when it comes to Lightning Components, we have many files in a bundle. Let’s say each of our bundles has 5 files. For 50 Lightning Components we have 5*50=250 files. This means if we took 10 minutes to rename 50 class files, we’d need 50 minutes to rename Lightning Components. (You might be thinking more music is the solution!)
There is an Idea here. Feel free to vote for it or leave it depending on how you feel after reading this post further. If you have a tech savvy friend, their solution might be to write some Python or Java or Node to help you with this issue. Or…
How About a Native Solution?
Let’s try to use the Developer Console Query Editor and update the names of the Lightning Components to see what happens. Run this query in the Query Editor.
Select Id, DeveloperName from AuraDefinitionBundle
Let’s change the name of the TestLighntingBaseComponents to CodeScienceLightningBaseComponents and hit save.
Boom. Problem Solved
If you have Lightning Components already moved to higher environments, you might want to create a destructive XML to get rid of old ones. Again, an extract from this table will help you.
Final Thoughts and a Word of Caution
Whenever you change something, always test. Even better? Write Selenium tests and hopefully – in coming releases (Safe Harbor) – we’ll see unit tests for Lightning Components like Apex.
Want to learn how CodeScience can help your business thrive on the AppExchange? Visit www.codescience.com/services today.