Lifecycle of Components

[UpperCod]

I invite you to create together an expressive and predictable lifecycle for your web components created with Atomico

[email protected] component recycling has been introduced, which allows redoing hook state but not property state, recycling only happens:

1. The component changes parent.
2. The component is removed from the document and then inserted back into the document.

Recycling is a utility to generate consistency with libraries that use this type of DOM manipulation, this also allows useEffect to be regenerated on recycle detection, example:

useEffect(()=>{
    // Mounted or New parent
    return ()=>{
        // Unmounted or Change of parent
    }
},[])

the above code is repetitive, I thought to simplify this by means of a new hooks called useMounted which would eliminate the need for the second parameter for useEffect, ideally this new hooks would alert the component what type of mounting is happening, either by recycling or by elimination .

useMounted(()=>{
    // Mounted or New parent
    return ()=>{
        // Unmounted or Change of parent
    }
})

Open questions

Do you think that the state of the hooks should be reset upon recycling?

[UpperCod]

I've thought about making the useEffect close run on browser idle times to improve performance

[TheJaredWilcurt]

Smells like React and it's failures.

Instead, copy Vue, which always takes what React has done, and then does it better:

• Have actual life cycle hooks
• Give them intuitive, obvious, predictable, guessable names, like:
  • created - component instance made, but not attached to DOM yet
  • mounted - attached to DOM
  • activated - when a component is swapped in, replacing another (like clicking on tabs)
  • deactivated - when a component is swapped out, being replaced by another
  • updated - The DOM is being re-rendered due to a change in state
  • unmounted - Component removed from DOM
  • destroyed - Component instance destroyed
• Also have hooks that run just prior to the action, instead of right after it:
  • beforeCreate
  • beforeMount
  • beforeUpdate
  • beforeActivate
  • beforeDeactivate
  • beforeUpdate
  • beforeUnmount
  • beforeDestroy

You don't need to do all of these, or copy them exactly, but this is a million times better than prefixing something with "use" (ew). or the most generic thing ever "effect" (ugh).