3 ms·
Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount()
by dheera 5y ago
Every time I see stuff like this
componentDidMount() {
I get driven away from React. It looks haphazard. Seriously? What about
componentDidntMount() {
componentWantedToMountButDidnt() {
...
I'm used to clean naming conventions like
void Component::on_mount() {
....
}
- cosmotic 5y agoMaybe the name is trying to communicate it happens after the component mounted instead of just before
- yuchi 5y agoThe 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 agoI 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 agoWhich languages in common industry use in 2022 have language-integrated aspect-oriented programming support?
- Jach 5y agoFair 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]
- JonathonW 5y agoWhen does on_mount run? React's componentDidMount() is a lifecycle method that runs after a component mounts, once it's been inserted into the DOM. This is in contrast to componentWillMount() (now UNSAFE_componentWillMount(), because it breaks when async rendering is enabled), which is called before the component mounts. This naming scheme becomes even more important for the update lifecycle methods-- in addition to componentDidUpdate(), there's a shouldComponentUpdate() called before it (where you can return true/false to tell React whether or not to proceed with the update) and UNSAFE_componentWillUpdate(), called between those two.
- qbasic_forever 5y agoWell, modern react is pushing folks to use the hooks model which jettisons the whole componentDidMount and other class functions. Now you use a side effect hook: https://reactjs.org/docs/hooks-effect.html https://reactjs.org/docs/hooks-effect.html This is a little more clear that it's for side effects of the component being put in the DOM, but it does require a bit more knowledge of react and hooks.
- unfocussed_mike 5y agocomponentIsNotThatBotheredButStarSighStarIfIMust() { ... }