reason-react-native: add example for ScrollView scrollTo method - #577

I used a switch for the example.

Btw, I noticed that scrollTo have scrollToParams & that scrollToEndWithOptions have scrollToEndOptions. What do you think about normalising naming with Params or Options (& same for similar places?).

@cknitt @sgny We could normalize & deprecate with warnings & remove deprecating warning in next major release?

I think I used the different names on purpose. In the case of scrollTo, we have a required params object (similar to the props object of a React component). In the case of scrollToEnd, we have an optional options object that may be supplied as an additional parameter to override some default values.

Not sure if this is consistent across the code though...

@cknitt I just find confusing the 2 namings. I get the idea.
But maybe we could stick to Option, since we might have xxx & xxxWithOptions ? (and xxxOptions would be the method to generate options).
Not sure if naming things option/param/argument are really different & clear for users. We should imo keep one & stick to it.

@sgny any comment?

I am open to changing these method args from "params" to "options".

Callback params like VirtualizedList.onEndReachedParams would remain as they currently are though, right?

I think the function name should remain scrollToEndWithOptions as that is consistent across the various modules. However, the optional argument could be renamed scrollToEndParams which would be more consistent with scrollParams and still be a reasonable name for what it is.

I find scrollToEndWithOptions with scrollToEndParams even more confusing.

I'd expect xxxWithYyy to take a yyy param...

I would go for just ditching one & keep only the other for simplicity.
Ditch "Params" & use "Options" everywhere. Or the opposite.
Having this kind of naming is anyway "confusing" somehow, so we should just have one.
Migration won't be a problem: we can deprecate call easily, people will have warnings, & next major release we remove them.

If we want to unify this, I am for "Options" everywhere.

How about instead of withOptions we use withOptional (or withOptionals)? Then we could have optional parameters or configs without causing much confusion.