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 ofscrollTo, we have arequiredparams object (similar to the props object of a React component). In the case ofscrollToEnd, we have anoptionaloptions 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 likeVirtualizedList.onEndReachedParams would remain as they currently are though, right?

I think the function name should remainscrollToEndWithOptions as that is consistent across the various modules. However, the optional argument could be renamedscrollToEndParams which would be more consistent withscrollParams and still be a reasonable name for what it is.

I findscrollToEndWithOptions withscrollToEndParams even more confusing.

I'd expectxxxWithYyy to take ayyy 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 ofwithOptions we usewithOptional (orwithOptionals)? Then we could have optional parameters or configs without causing much confusion.