GithubHelp home page GithubHelp logo

Comments (5)

acdlite avatar acdlite commented on June 16, 2024

Not sure about this. If you need to use componentDidMount() or any of the other component lifecycle methods, at that point you should probably use a class component.

from recompose.

lukewestby avatar lukewestby commented on June 16, 2024

Thanks for the response, and I totally understand if you don't want to include this feature at the moment, but just for discussion now:

This library covers most of the useful Component API surface, which I think componentDidMount() is in at least in the case that I mentioned, and its stated intention seems to be to eliminate the need for extending Component or calling React.createClassin favor of functional style, so I guess I'm having a hard time understanding why componentDidMount() would not qualify. Could you explain why you think componentDidMount() is better handled by extending Component?

from recompose.

istarkov avatar istarkov commented on June 16, 2024

IMHO:
The most common case in componentDidMount is to use refs for component Dom events, for jQuery plugins like integration,
(the other case is for events like resize)

But internal refs for stateless component is gone every new render, (and stateless component doesn't have each own ref) so it's impossible to use this common case.
Also how to access internal component refs without some hackable api?

from recompose.

lukewestby avatar lukewestby commented on June 16, 2024

I definitely see where you are coming from and agree when it comes to using refs. Another example that I have frequently encountered, however, is for components that need to update state on window scroll events for some visual effect, virtualization purposes, etc. In these cases refs haven't been necessary but I do need to call window.addEventListener() on the client. I get that this use case might be too specific to warrant inclusion in the library itself. It would be totally fine to write a custom HoC and use compose() -- excellent API design, btw 😄

Thanks!

from recompose.

acdlite avatar acdlite commented on June 16, 2024

I'm hesitant to add support for other lifecycle methods because lifecycle methods usually need to call setState() or save references to a subscription on the component instance. Both of these go against the functional nature of Recompose's API. I'm still not sure if the existing lifecycle() helper shouldn't be removed.

I'm going to close this issue, but if you have an idea for an API, please let me know :)

from recompose.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.