Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subs or Substitutions? #53

Closed
rbiggs opened this issue Feb 7, 2017 · 9 comments
Closed

Subs or Substitutions? #53

rbiggs opened this issue Feb 7, 2017 · 9 comments
Milestone

Comments

@rbiggs
Copy link
Contributor

rbiggs commented Feb 7, 2017

I really like the API, a complete copy of ElmArchitecture in JavaScript. My only peeve is subs. I think it would be better to use the term subscriptions like Elm and Choo. I remember the first time I looked at the counter example and saw the sub function in the update method. I immediately assumed it was a singular instance of subs, whatever they were. Then when I saw the subs in actions I was thinking, hmmm... substitutions?, subtractions? subordinations? subscripts? or maybe he wants to give us all foot long subs!!! Yay! I'll have two please. OK, I know you used subs to save a few letters typing, but going forward if you want this project to gain traction it would be better to use the more explicit term subscriptions to save people the mental work of constantly translating subs to subscriptions in our heads. Even in your README you describe subs as: Subscriptions are functions that run once when the DOM is ready. Use a subscription to register global events, like mouse or keyboard listeners. I'm suspecting you probably just lobbed off the tail end of pubsub for the term. My point is explicit terms are always better than implicit terms in API design. It's not like people would have to type the term a thousand times. It's just once. Then when you scan the page and see subscriptions it would be immediately clear what you are looking at, even if you were not familiar with this API.

@jorgebucaran
Copy link
Owner

It's not like people would have to type the term a thousand times. It's just once. T

Good point.

What do you folks think? @danigb @itrelease @maraisr @tzellman @evgenykochetkov @terkelg

I'm 💯 with the idea.

@itrelease
Copy link
Contributor

I think it's a good idea considering that it's inspired by Elm.App it would be nice to go along with same naming for api

@tunnckoCore
Copy link

I was thinking the same thing. subscriptions is better if you want shorter name subscribes is better than subs too.

@tzellman
Copy link
Contributor

tzellman commented Feb 7, 2017

I like subs for brevity, but I agree that subscriptions may be more obvious. You could always settle with var subs = options.subscriptions || options.subs || {}.

@terkelg
Copy link
Contributor

terkelg commented Feb 7, 2017

I agree, good idea!

@rbiggs
Copy link
Contributor Author

rbiggs commented Feb 7, 2017

subs is an array, so its description should be a noun, not a verb. subscribes would indicate a function.

@jorgebucaran jorgebucaran added this to the 0.0.13 milestone Feb 7, 2017
@jorgebucaran
Copy link
Owner

jorgebucaran commented Feb 9, 2017

@rbiggs Changed to subscriptions. Code still handles and will handle .subs for a while, at least after >=0.0.13, examples have been updated and due mourn time has been given.

@FlorianWendelborn
Copy link

@rbiggs Can this be closed?

@jbucaran Is there anything else to do before releasing 0.0.13? I'd like to have the subscriptions fix available for usage. 🙂
In addition to that 0.0.12 changed the import to hyperapp/hx and the longer we wait to undo this the more people will use that change just to undo it in 0.0.13.

@jorgebucaran
Copy link
Owner

Shipped. See the release notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants