WeakAuras

WeakAuras

206M Downloads

Wipe aura_env each aura load to enable stateful behavior

4ndrewCox opened this issue ยท 5 comments

commented

Is your feature request related to a problem? Please describe.

Specific example:

  • Aura is set to load on HiveMind encounter
  • Aura is looking for a spell to be cast
    • custom trigger returns true to show an icon
    • untrigger when spell is found to be successfully cast in combat log

On first load, the aura works fine, aura_env.spellCast = false, then in the hide trigger, aura_env.spellCast is set to true, so the primary trigger doesn't return true anymore.
Second aura load, aura_env.spellCast is still true, and so my aura is not showing the icon.

I got around this by managing my own state by tracking when the encounter starts and setting aura_env.spellCast to false, but this is a work-around I'm not happy with, as I feel aura_env itself should be wiped each new load, then I could do a '~= nil check' to set it as false.

Describe the solution you'd like

By having aura_env do a wipe of all player defined variables, aura_env could then be treated in a more stateful manner by doing a ~= nil check if the variable is defined to set initial state. In this way your trigger behavior will always be consistent each load.

Describe alternatives you've considered

As described in the problem statement, I implemented a work-around, but it required the extra step of tracking ENCOUNTER_START.

Additional context

I feel that promoting a pattern of state design will only benefit everyone. Refer to React/Redux.

commented

This might be desirable if we were to create the system today, but it's far too late to change it now. Too many things would break.

commented

Would it not just be a function call to wipe(), then call your init function to set the predefined variables back?

commented

The implementation details aren't the problem. The problem is that there are far too many auras that exist already which would immediately break if we did this.

commented

Then can I propose a configuration option be added to toggle this behavior?

commented

No, I don't think that we'll do that.