While we plan to not initialise app specific tracking functionality within n-tracking, we have accepted that tracking functionality of a site wide nature, should probably be initialised within n-tracking. This way, the responsibility of initialising them don’t fall to app developers (which is especially important when new apps are created). The problem this introduces, however, (which is a problem currently being experienced by the current n-ui tracking implementation) is that it becomes possible for tracking functionality to become redundant overtime without anyone realising it. There are various reasons why it's in our best interest to catch redundant code, one of them being that such code (due to being client side code) will negatively impact the bundle size. Any thoughts on how this issue can be addressed? Is it worth looking into a tool / service that tracks usage and notifies us whenever custom tracking functionality becomes redundant?
While we plan to not initialise app specific tracking functionality within
n-tracking, we have accepted that tracking functionality of a site wide nature, should probably be initialised withinn-tracking. This way, the responsibility of initialising them don’t fall to app developers (which is especially important when new apps are created). The problem this introduces, however, (which is a problem currently being experienced by the currentn-uitracking implementation) is that it becomes possible for tracking functionality to become redundant overtime without anyone realising it. There are various reasons why it's in our best interest to catch redundant code, one of them being that such code (due to being client side code) will negatively impact the bundle size. Any thoughts on how this issue can be addressed? Is it worth looking into a tool / service that tracks usage and notifies us whenever custom tracking functionality becomes redundant?