Neodigm SodaPop | Life Cycle Events

[neodigm]

This fix needs to be documented. The events behavior should be consistent for all components.

On Before Open - determines if open is allowed - Before DOM is appended
On After Open - determines when unhide (opacity) happens - After DOM is appended but before content is revealed.
On Close - determines if close is allowed - Before Close

[neodigm]

Why -- This is important from a DX perspective because SodaPop is usually the first component learned. Would suck if a dev had to unlearn it, in order to use the more modern components. So, yes this is a retrofit, but I would not say its breaking.

[neodigm]

Regarding OnBeforeOpen: If the specific CB (has id) returns false (canceling open) then the DEF will not fire. The prevents the generic DEF from canceling out an explicit cancelation.

 if(this.fOnBeforeOpen[ _sId]) bOkOpen = this.fOnBeforeOpen[ _sId]( this.sId )  //  The specific can cancel the generic
 if( bOkOpen && this.fOnBeforeOpen["def"]) bOkOpen = this.fOnBeforeOpen["def"]( this.sId )

[neodigm]

Breaking - Backward Compatibility | To support backward compatibility and, I think make the Life Cycle callbacks more forgiving; On Before Open and On Close simply requires a specific FALSE (===) to cancel. Not falsey - undefined - 0 - empty string.

If legacy implementation callback returns an UNDEFINED (which is pretty common) it will not stop the Soda Pop or Pop Tart instance from closing / opening.

This made for some awkward code, but pays off in our commitment to DX.

let bOkClose = true  //  CBs must explicitly return false to prevent closing
if( this.fOnClose[ sId ] ) bOkClose = !(this.fOnClose[ sId ]( sId ) === false)  //  The specific can cancel the generic
if( bOkClose && this.fOnClose["def"] ) bOkClose = !(this.fOnClose["def"]( sId ) === false)
if( bOkClose ){
    // stuff
}

[neodigm]

This is fixed in v3.0. We now have a standard interface contract for dealing with component life cycle events. Each component may handle it a bit differently, but overall the contact should be rational.

Documentation is going to be an on-going process, because the subject matter is advanced and applies to the entire framework. We should create a Life Cycle overview recipe and infographic, and one recipe for each component.