event emission outside most/create closures and dropping support for most.create

mostjs-community / most-help

raising and archiving FAQs, beginner doubt, need for general help (not involved with most dev) for cujojs/most

1 stars 0 forks source link

event emission outside most/create closures and dropping support for most.create #1

Open sourcevault opened 6 years ago

sourcevault commented 6 years ago

QUESTION 1

I know this must have been answered somewhere but ..

why is this an issue ?

(taken from @most/create)


// Unsupported:
let emitEvent, emitEnd, emitError

const stream = most.create((add, end, error) => {
  emitEvent = add
  emitEnd = end
  emitError = error
})

emitEvent(123)
emitEnd()

Is there something about lazy streams that makes supporting emission outside closures a bad idea ?

QUESTION 2

for most.create why is it a Backward compatible port

Backward compatible port of most.create as a separate package

Shouldnt the ablity to glue most into other systems in the wild be given core priority ?
most.fromEvent is quite limiting to the endless ways people expose events in the nodejs ecosystem.
For example my current project I am trying to expose operation system syscalls-

@most/create is intregal to that task, the idea that it might not be core to most worries me.

davidchase commented 6 years ago

hey @sourcevault 👋 I'm curious are these questions you have here, something that you want answered from mostjs users or from the core team?

i think most-help within the mostjs community is an interesting idea i think it could definitely help folks using the library with some answers especially ones that have been answered and lost in slack or gitter conversations. I think its awesome to connect with people over those communication applications but having forums/github issues or indexed archives of QAs is still better IMO for discovery and dissemination of knowledge.

sourcevault commented 6 years ago

@davidchase hey !

To your first question - it could come from anyone really.
gitter is quite inefficient, its difficult to search and not asynchronous like email - so unless you are available all the time you are unable to have discussions.
The idea is not new, check out https://github.com/libuv/help/issues. I am quite impressed by it really, since its a superior way to accumulate knowledge then Stack Overflow - for example if you are having some issue with most searching on SO wont get you very far, but here it would be trivial.
It would be nice if we could turn the issues into a git repo itself ! like fossil-scm. The best option would be to raise issues as pull requests (isssue1.md file) to this repo and write your answers to that readme file.
But raising it as an issue in my opinion is more user friendly - even though its non portable (knowledge will be lost if github shuts down ).