Take last event and subscribe mode

[jimmyheaddon]

Hello, rather than always replaying from the first event in a stream, could subscribe() have an overload mode to take the last event and then poll at the configured interval from then on?

Thanks!

[camjackson]

I'm open to adding something like this, but I'd like to know more about the use case first.

The usage pattern I had in mind for this library was to always page through the whole event stream, in order to calculate the current state. When would you want to only receive new events?

[jimmyheaddon]

Hi @camjackson, we're already building the state snapshots upstream in Event Store, chained from other Event Store streams that contain the individual state changes. Essentially we're already doing the reducer work, so we just want to subscribe from the latest event and continue

[camjackson]

Sounds like a reasonable way to do things.

I'm flat out with other OSS stuff at the moment, so I'm not sure when I'd have time to implement this. But I'm definitely open to a pull request ;)

For anyone who wants to pick this up, it would mostly be a change to the streamSubscriber module. At the moment there's a hardcoded initial stream index of 0. It shouldn't be too hard to add an extra flag that will make it initialise that index to whatever the current length of the stream is.

[jimmyheaddon]

Hi @camjackson, I went to create a PR, then realised that streamSubscriber was completely different from the version I pulled from npm, in that the npm version has a large switch statement in streamSubscriber, but this version in this repo is significantly smaller? I can't find the npm version in this repo on any old branches or tags, any ideas?

[camjackson]

This project is using some bleeding edge javascript language features that aren't supported by node yet. So before publishing to npm, I use babel to transpile the code down to something that node can understand.

The code from your screenshot is what that output looks like. It's machine-generate code, which is why it's a bit nasty to read. Best not to look too closely at it. 😉

The code on github is what you want to be writing your pull request against.

[jimmyheaddon]

Ah nice one, just checking I didn't have something old!

I basically want to put 2 PR's together, one as discussed above, and another that adds the stream metadata to the reduxEvent object, as shown towards the bottom in the screenshot above. Would you be interested in that?

[camjackson]

Not sure about having the stream metadata in the event object, but I'm open to the idea. If you've already got some code for it, go ahead and open a PR and we can discuss it :)

[jimmyheaddon]

@camjackson I've raised a PR for the metadata suggestion. I can put together another PR for this once we've discussed that?

[camjackson]

Thanks, will take a look in the next day or so.

Happy to do both PRs in parallel if you want, although there will probably be merge conflicts, so separately might be easier. I'm happy either way.

[jimmyheaddon]

Yeah I figured separate might be easier, I'm in no immediate rush, and given it's in the same area of the files, and I don't know your coding or testing preferences, I opted for the sequential approach :)