Support method detection as well

[jherr]

It appears the current code only detects properties. It would be great if it could detect methods as well.

[fkling]

I assume you mean, given

class Editor extends React.Component {
 /**
  * Get the value of the editor
  */
 getValue() {}
}

it would extract getValue and its docblock so that it's clear that given a ref to the component, one can call getValue on it?

[jherr]

Yes. :-) Thanks for a much better bug report.

[fkling]

Sounds reasonable to me. I think it is common to prefix internal methods with an underscore _, so I think it makes sense to only look for methods that are not prefixed as such.

Of course this could still extract data that is not needed, but then again, it can also just be ignored when generating the actual documentation.

[jherr]

We do the _ as private thing, but I'd be happy to just write the ignore code on the consumption side. Or you could have an option for ignoreUnderscoreMethods or something. Your code, your call.

[scvnc]

Should this feature request include static methods as well?

[fkling]

@scvnc: I don't see why not!

[aweary]

@fkling any status update on this?

[fkling]

@aweary: Sorry, I just didn't have the capacities so far to work on this. I might be able to get to it soon, otherwise PR's are always welcome!

[janicduplessis]

Working on this for the RN website, I'll submit a PR when I get it working there.

[danez]

I have a working version for es6 classes, although I think it is not ready to integrate, because it is a mix between reading jsdoc and flowtype.
We also use jsdoc annotations to see if the method should be included in the docs (@api present, and not @private or @protected) and not start with _.
https://gist.github.com/danez/ed81356bc04dc60a59b4

[janicduplessis]

That's great, I got it to work for React.createClass yesterday also using a mix of reading jsdoc and flow types. I'll probably use your implementation as a base as mine was done using a custom handler directly in the RN website.

I think the logic for choosing which methods are included should be left to the clients so they can choose their own rules. We just provide all the info they can need (method name, access modifiers from jsdocs). We can just filter react methods.

[danez]

In the gist the parsing of jsdoc is missing i noticed, but basically it just uses eslint/doctrine to parse the docblock.

[janicduplessis]

I used tj/dox which does pretty much the same but doctrine seems better as it's doing only what we need and dox is a lot bigger.