Road to v1

[WickyNilliams]

Thought I'd gather a rough plan, and list of possible changes, for v1:

• drop async behaviour when initialising (drop async behaviour of init #346)
• simplify API (Feature/simplify api #352)
  • I don't think there's much in having consumers new up an instance and then call init().
  • A simple function headroom(elem, options) should do
  • update docs
• maybe drop callbacks in favour events emitted on elem?
  • this would further simplify the API
  • we could support both callbacks and events as interim?
• work out what to do with angular/jquery plugins
  • jquery is so simple it's almost pointless!
  • someone has ported headroom to angular: https://github.com/TypeCtrl/ngx-headroom. should we just recommend people use that?
• fix all the outstanding iOS issues
  • first step will be to verify if all are still valid
  • may need to enlist someone with an iOS device, as I have none
• rename Headroom.cutsTheMustard to Headroom.isSupported (rename cutsTheMustard -> isSupported #351)
  • update docs

I've created a v1 branch which is where i'll gather all these changes. This allows me to work on breaking changes in isolation, and still be able to publish any bugfixes on master.

If anybody else has any other suggestions, please let me know.

[clxmstaab]

todo: define which browser are considered supported and mention them in the README

[fuzzzerd]

• work out what to do with angular/jquery plugins
  • jquery is so simple it's almost pointless!
  • someone has ported headroom to angular: https://github.com/TypeCtrl/ngx-headroom. should we just recommend people use that?

I would hate to see framework specific parts leaking backwards into the core. I think its better to keep the core package agnostic, and then create framework specific packages.

[WickyNilliams]

@fuzzzerd there's no plan to change to the core library. I'm thinking I'll just completely drop the jquery plugin and angular module altogether

[lkraav]

work out what to do with angular/jquery plugins

I'm somewhat confused on whether it's possible to refactor the core library to such that framework integrations wouldn't have to copy-paste the whole scroll detection business logic anymore?

[WickyNilliams]

@lkraav that would be the ideal situation, yes. Then people could just create thin wrappers around the core logic.

I've made a load of perf and big fixes recently that won't make it into react etc ports because the business logic is copy and pasted. This is a shame.

I think by the time v1 is done we will be in a better position to explore this route. Though if you'd like to try it now, please go ahead and report back where it falls short :)

[saas786]

@WickyNilliams Any further progress on this?