I still use them regularly, but not often for versioning as they're allocated at a component level and not for attribute modifications - perhaps in later releases we'll see an extension of their use.
What I do see all the time is components with a condition type of "never". This is probably because it's the quickest way to turn off features that are broken or those you're not ready to completely remove for whatever reason.
The issue with this is they get forgotten. Future maintainers see these components in limbo and wonder if they should be removed or enabled, particularly if they lack comments regarding their status.
I have encountered valid circumstances when a report region is purposely set to "never" - where a link is available to export the relevant data as CSV.
Instead I would suggest creating a build option that looks like this:
 |
| Build option - to be removed |
'Default on Export' being the same as current status means it will stay excluded as the application moves between environments.
One major advantage I find is the accompanying utilisation report. At some point during the project I went through everything I've allocated 'to be removed' and decided if it truly was time to sent these components to /dev/null.
 |
| Build option utilisation report |
2 comments:
It's worse than you think, with some Dynamic Actions being tied to Regions set to Never. You cannot change a Dynamic Action region through the front-end developer tool. So you get stuck some old Regions so that you don't need to copy the Dynamic Actions. If you remove the region and keep the DA, the Apex app will fail to build or import.
Not sure if this still happens in Apex 5.
I'm not entirely sure what you mean, but I think I know what you're getting at. Something to keep in mind.
Post a Comment