The road to 1.0.0

[rdmurphy]

Hello! I wanted to open up a space (and try out GitHub's new Discussions feature) to give users of Scroller a chance to speak up and give feedback on the state of the library and what it'd mean to go 1.0.0.

I can only speak for my work and the work of my colleagues at the LA Times, but despite this library having comfortably sat at 0.1.0 since it's initial release, I think it may be time to commit to a major version release. It's possible that nothing changes in that process, and it's simply a version bump! Or — there are some fixes and tweaks worth considering.

Please let me know here if you have thoughts. If I decide something makes the cut and should be an actual issue, we'll migrate further discussion there about that specific feature.

Thank you!

[rdmurphy]

One change I've already loosely considered is reworking the event emitter interface to no longer be string based and to provide actual functional hooks to each event.

So instead of:

scroller.on('scene:enter', d => {
  d.element.classList.add('active');
});

It'd be:

scroller.onSceneEnter(d => {
  d.element.classList.add('active');
});

I think the string-based interface can be a bit error-prone (one typo and it's quietly failing), and it also loses out on the concrete type hints having a specific function call could provide.

[lukeed]

You can solve the error-proneness via an interface for on() values. It's still not a guarantee, but it's one extra layer of protection.

I'd let byte size and performance (if it matters) dictate the API design. I personally prefer the look of the emitter approach, but onSceneEnter isn't too bad either :P

[rdmurphy]

That's a good point! I also realized after writing that out that this change would also require an offSceneEnter/removeSceneEnter to match it if the goal is feature parity. 😬 Not the end of the world, but likely would be a net negative (positive...?) in byte size for sure.

[lukeed]

Yeah, if detaching is part of it then I'd almost definitely lean towards on() -> Unsubscriber since that pattern is proven/common.

As far as size is concerned, you can look to vegemite for some tricks :) While not common advice, I'd definitely recommend dropping class syntax here since there's no real point (afaict) in checking for instanceof later on.

[lukeed]

Hey~!

So I know it wasn't asked of me, but I set forth some pre-1.0 PRs to whittle down the size even further before breaking changes are introduced. I was playing with this version locally and I have to say, the event emitter / on() approach feels really nice. My only suggestion for changing the future API is to return that unsubscriber from on() so that one could inline a handler instead of hoisting it for later reference. This could even be a bound copy of off() – via $.off.bind(0, type, handler);. But I would definitely not consider this a must-have... hosting a handler for reference is perfectly reasonable.

[rdmurphy]

Hey! Thank you so much for doing this — I'm gonna try to take a closer look today/early this week. Sorry to have been a bit of a ghost, was a little overwhelmed with work/the state of the world. Very excited about these suggestions though! 🙌

[lukeed]

Not to worry at all 😅 Completely understandable.