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

[sourcevault]

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]

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]

@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 ).