Why accept arg #2 (centerIfNeeded) and options.centerIfNeeded? about scroll-into-view-if-needed

[stipsan]

You are right the interface have turned messy as functionality got added.

I've just finished setup semantic-release on this project to make it easier to do new releases.
Next on my list is to setup a simple testing suite using SauceLabs to get good browser coverage to prevent regressions and to catch bugs.
After that I intend to refactor the API signature and update the docs.
The new signature will be much simpler. Something like:

export interface AnimationOptions {
  duration?: number;
  easing?: 'ease' | 'easeIn' | 'easeOut' | 'easeInOut' | 'linear' | Function;
  step?: Function;
  done?: Function;
}

export interface ScrollIntoViewIfNeededOptions {
  centerIfNeeded?: boolean;
  boundary?: Element;
  animate?: boolean | AnimationOptions;
}

export default function(
  node: Element,
  options?: boolean | ScrollIntoViewIfNeededOptions
): void;

So if you pass a boolean as the second argument you get the same behavior as in browsers that have the native implementation. Pass an object and you can customise it 😄
If you pass true to options.animate it'll use the default animation settings, or pass an object with options and it counts as true. By default it's false.

[stipsan]

The reason why the second argument exists is because it exists in the native implementation: https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoViewIfNeeded
And I didn't think about toggling between a boolean for backwards compatibility and an object with options for convenience. I regret that now 🙂

However it is confusing indeed. Work is done to make these features part of the scrollIntoView spec:

• https://drafts.csswg.org/cssom-view/#dom-element-scrollintoview
• https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#scrollIntoViewOptions

[stipsan]

This is no longer an issue in v2