streams or emitter

[Julian Gruber]

I have the following use case:

I want to display a list of entries that both gets new entries pushed to - inserted at top - and historical ones appended at the bottom, if you click 'show more'.

now what's the cleanest way of doing this? (although this is in a browser environment, I use streams (github.com/juliangruber/stream) and eventemitters (github.com/component/emitter), so this is a node topic.

Possibilities I've come up with:

Use one stream that emits entries with dates and the list inserts them at the right position. The stream has to now how many entries it has to fetch from the api, initially and on 'show more'. Not very streamy...

Use two streams. streams.new streams to the list's top, streams.historical to the bottom (including the initially fetched entries). This way the list can be dumber as it doesn't have to reorder.

Use one stream for new entries and one emitter for historical ones, as they by concept are not streamed.

Use a stream for new entries and fetch historical ones with standard api calls and callback style.

Use one emitter that emits entry/new and entry/historical.

Or is there another way of dealing with 'two-way-streams'. This should be a common pattern in realtime applications!

[Austin William Wright]

On Wednesday, September 26, 2012 11:22:45 PM UTC-7, Julian Gruber wrote:

Or is there another way of dealing with 'two-way-streams'. This should be a common pattern in realtime applications!

I believe in computer science this is called a double-ended queue, or simply deque. Appending to the bottom would be called a push, prepending an element to the top would be called unshift -- just like the methods in an ECMAScript Array.

[Christian Tellnes]

I implemented something like this a while back. I went for the
solution where I emitted new entries while I used callbacks for
historical entires.

New entries could come in anytime unlike historical that always was
the result of a user action.