headroom.js
headroom.js copied to clipboard
Road to v1
Thought I'd gather a rough plan, and list of possible changes, for v1:
- [x] drop async behaviour when initialising (#346)
- [x] simplify API (#352)
- I don't think there's much in having consumers
new
up an instance and then callinit()
. - A simple function
headroom(elem, options)
should do - [ ] update docs
- I don't think there's much in having consumers
- [ ] 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
- [x] rename
Headroom.cutsTheMustard
toHeadroom.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.
todo: define which browser are considered supported and mention them in the README
- 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.
@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
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?
@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 :)
@WickyNilliams Any further progress on this?