LibUnitIDLibUnitID provides consolidated change event callbacks and identity caching for all of the event-trackable unitids. Currently, the supported unitids are:
vehicle, vehicletarget, pet, pettarget, target, targettarget, focus, focustarget, party#, party#target, partypet#, partypet#target, raid##, raid##target, raidpet##, raidpet##targetand they are updated by the events:
PLAYER_TARGET_CHANGED PLAYER_FOCUS_CHANGED UNIT_PET UNIT_TARGET PARTY_MEMBERS_CHANGED RAID_ROSTER_UPDATEIf your addon or library needs to react to changes in the identity of any of these unitids (which means you probably register some or all of these events), then you can reduce your code's complexity (and probably gain a bit of performance) by using LibUnitID. The goal is for no other library or addon to have to worry about event registration for the basic (event-trackable) UnitIDs: "target", "focustarget", "party3", "raidpet22target", etc. Any time any of these UnitIDs change their identity, LibUnitID provides a callback. This includes "cascade" changes: for example, UNIT_PET("party3") indicates that "partypet3" has changed, which probably also means that "partypet3target" has changed. LibUnitID detects this automatically and notifies any callbacks that are registered for any affected UnitID. In addition to (and as a side effect of) tracking UnitID identities and issuing callbacks, LibUnitID caches the GUID associated with each UnitID. Querying this information from LibUnitID's cache takes slightly less than half the time as calling the built-in UnitGUID() API function, while maintaining this cache takes slightly more than twice as long per UnitID as a single UnitGUID() call. This means that if UnitGUID() is called for the same UnitID more than ~5 times per actual identity change, the caching mechanism yields a net performance gain. While tracking every supported UnitID in a 5-person instance run, informal testing has shown upwards of 100x as many UnitGUID() calls as cache updates -- well beyond the break-even point.