Recompose: LifeCycle: ComponentDidMount Example

[brunobraga95]

Anyone could give a precise example of how I can use lifecycle? I need to use ComponentDidMount and access the DOM, I know it is not a good practice but it is the only option I have. I also with all due respect, would like to advice recompose team to improve the documentation. As a beginner with react, I find it kind of hard to understand the methods without examples and etc.

thanks

[istarkov]

Hi,
it's an open source project and if you think that documentation needs to be updated - please welcome.

For examples in any project you can use tests sources - all of them are good examples.
And just source code.

Most recompose methods are simple and small, in current case this is the source of lifecycle.
Almost no logic as you could see. Almost nothing to write in documentation :-)

[bholloway]

@istarkov I hope there are contributors that can help. @brunobraga95 and I are trying to learn and, by definition, are not in a position to generate such documentation... Maybe in time.

The source code for lifecycle does not help unless you understand the components/utilities it leverages: createEagerFactory -> createEagerElement -> createEagerElementUtil.

I do like how clean this makes the implementation. However while these lower-level components are simple they are abstractions, and it is not clear at first glance what they are doing. It would be nice to document in a how it works section, or at least have a comment block for these components.

Given that I agree that you could look at the lifecycle code and see what it is doing.

EDIT - I can see some discussion in this the performance docs. However I think most of the 'should I use this' is better termed 'how-it-works'. This library is good stuff: assume that people do want to use it and front-focus their learning.

[bholloway]

It looks like the lifecycle wrapped component will always re-render. So it needs to be composed with shouldUpdate() HOC or implement similar in its own spec.

I'm guessing this is the general philosophy? - All these components are small building blocks that attend to separate concerns, and you need to compose() them.

I think that is a big positive and is worth mentioning at the top of the API docs. It has definite implications on how people should approach things.

[istarkov]

About re-renders,
In most cases you should not avoid re-renders,
React is fast enough to work without all that shouldComponentUpdate.

I see that people overuse optimisations, using them everywhere by default without any sense.
Having my experience any custom shouldComponentUpdate (by custom I mean that it's not just shallowEqual compare) will become a problem (bug) in the future.

About philosophy
Hard to translate, but isn't that already mentioned at the top of documentation
https://github.com/acdlite/recompose/blob/master/docs/API.md#api

[istarkov]

About docs ;-)
It's well known that documentation of any project can be improved, BTW we all have the excuses to not doing this.
You - that you are just learning and so not in a position to generate ...
Me - I have poor english skill so ...
Someone - All is fine why to change something
Someone else - Any reason to not doing this ;-)

[bholloway]

Thanks @istarkov. I've also been looking through some of the other issues. I like how there seems to be lots of discussion and assistance on this project. That is always more important than docs!

[wuct]

@bholloway Thanks for your input. I think we should document what is the eager element and what is it for, because, obviously, it's the first obstacle to get into the source code.

[wuct]

A PR will be welcome if anyone want to enhance this part of doc.