By doing it that way I would not spend a large part of my 250 evars on mapping each of the below eventInfo properties to their own eVar and similar events per type
Button Clicked (event)
Tab Clicked (event)
Tab Panel Showed (event)
Tab Panel Hid (event)
List Item Clicked (event)
accordions, forms, hover/touch events etc... imagine how quickly you will run out of eVars and events (evars before events probably, but still).
We need to track a lot of (not just talking a few cta clicks) clicks and other user interaction events all over the UI, so I'm concerned how this will scale and can forsee how we will quickly run out of eVars if we follow that approach.
Which is why I thought it would work well to not use evars for each concrete type of component/element (button, tab, listitem, accordion etc) but breakdown the componentId dimension by another dimension / evar, component resource type. But then, if all components we track is mapped to evar1=componentId we might run into a scalability issue with the 500000 unique evar values and low traffic limitation.
So as I see it for AA to scale well with a pure EDDL based setup, we need A LOT more evars and events at our disposal, or we need that max unique evar limitation to be lifted? Is this just how it is for now, since evars / success events and the Adobe Analytics architecture was not built to support EDDL which is a somewhat new approach to tracking? Are there plans to support EDDL better (what can we expect and a rough ETA, so we might start today, in hopes it will scale when new features / limitations come later this year perhaps) or what am I missing?