21 ms·

The reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from

by yuchi 5y ago

The reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from Mac OS X/iOS patterns and allows the name to convey the “when” of the listener. It is not “during component mounting” it is “after it did”.

Jach 5y ago
I guess this is just a limitation of JS the language showing itself. Other languages have actual aspect-oriented support where before/after/around methods are very clear name-wise and semantics-wise (if not always so clear without tooling support what happens if you come across a 'mount()' call). Maybe it's time for a new JS framework! /s
- vertex-four 5y ago
  Which languages in common industry use in 2022 have language-integrated aspect-oriented programming support?
  - Jach 5y ago
    Fair point. I hinted with the idea of a new framework that you may be able to bolt something acceptable on top of JS (I'm sure it's been done already in the past with some framework) especially if you just want the before/after/around advice features of AOP without other stuff. Or perhaps go into custom syntax transpiled to JS/TS-then-JS since no one seems to mind heavy build processes these days. For the most common industry use, I'd have to say it's still Java's Spring AOP/AspectJ. Maybe it's not language-integrated, but it's pretty close. For an uncommon use example of what could be possible: (defmethod react.component:mount :after ((self counter)) ...) ; instead of componentDidMount (defmethod react.component:update :around ((self counter)) ...) ; instead of shouldComponentUpdate (defmethod react.component:unmount :before ((self counter)) ...) ; instead of componentWillUnmount ; (the react.component namespace qualifier could be whatever else and not necessarily typed out) However closely you integrate it with the language, having that machinery generally available seems better for naming and for providing new lifecycle functionality, without everyone having to reinvent the wheel and provide it in different incompatible ways. But it's clearly not a big issue.
    - deleted 5y ago
      [deleted]

by yuchi 5y ago

Jach 5y ago

I guess this is just a limitation of JS the language showing itself. Other languages have actual aspect-oriented support where before/after/around methods are very clear name-wise and semantics-wise (if not always so clear without tooling support what happens if you come across a 'mount()' call). Maybe it's time for a new JS framework! /s

vertex-four 5y ago
Which languages in common industry use in 2022 have language-integrated aspect-oriented programming support?
- Jach 5y ago
  Fair point. I hinted with the idea of a new framework that you may be able to bolt something acceptable on top of JS (I'm sure it's been done already in the past with some framework) especially if you just want the before/after/around advice features of AOP without other stuff. Or perhaps go into custom syntax transpiled to JS/TS-then-JS since no one seems to mind heavy build processes these days. For the most common industry use, I'd have to say it's still Java's Spring AOP/AspectJ. Maybe it's not language-integrated, but it's pretty close. For an uncommon use example of what could be possible: (defmethod react.component:mount :after ((self counter)) ...) ; instead of componentDidMount (defmethod react.component:update :around ((self counter)) ...) ; instead of shouldComponentUpdate (defmethod react.component:unmount :before ((self counter)) ...) ; instead of componentWillUnmount ; (the react.component namespace qualifier could be whatever else and not necessarily typed out) However closely you integrate it with the language, having that machinery generally available seems better for naming and for providing new lifecycle functionality, without everyone having to reinvent the wheel and provide it in different incompatible ways. But it's clearly not a big issue.
  - deleted 5y ago
    [deleted]