API: proposal to rename or add alias for 'createSaga'

[BrainCrumbz]

This might be interesting, especially before the official v1.0.0 goes out.

Couple of observations:

• createSaga returns an Angular2 Provider, not a Saga. I'd argue that usually by invoking createFoo, one expects to obtain a Foo instance
• createSaga accepts a SagaFactory, whose existence and duty is just to actually create Saga, as to say "it's the factory that creates the saga, not createSaga"

Those lead me to think that a much revealing, less confusing name would be provideSaga, instead of createSaga.

I understand that renaming is a breaking change, so that's why adding an alias might be a more suitable path.... although while still in beta, at least I would deprecate the original name and favour the alias.

[MikeRyanDev]

Agreed. Right now I'm working on implementing a version of store-saga that does not use any middleware APIs. Once that is settled, I'll make this name change and move the project over to ngrx.

Thank you!

[BrainCrumbz]

You're welcome! Just out of curiosity (and basically off-topic), what is wrong with store-saga being a middleware? That seems a perfect fit for such a library ... well, even redux-saga in redux world is a middleware.

[MikeRyanDev]

It actually isn't necessary to use the middleware APIs here. store-saga's implementation is surprisingly simple underneath the hood:

store$
  .withLatestFrom(dispatcher$)
  .map(([ state, action]) => ({ state, action }))
  .let(saga)
  .subscribe(dispatcher$)

Doing so would solve the persisting issue of people wanting to inject Store into their saga providers.

[MikeRyanDev]

@BrainCrumbz I have a question for you. When I move this to ngrx, I think I want to go ahead and change the name of the library as well. While store-saga shares some DNA with redux-saga, they actually remind me more of Elm's effects or Cycle.js's drivers. I'm considering calling the library @ngrx/effects or maybe @ngrx/side-effects. Thoughts?

[BrainCrumbz]

Well, thanks for the honour, first of all!

Just so that you put those thoughts in perspective: we've a strong background in AngularJS, C# and there we met ReactiveExtensions, which we fell in love with: it's amazing how such a library can lie almost unknown for such a long time (sorry, OT). Before then we were interested in "functional" things (LINQ, JS array operators, underscore). Then we've been very interested about redux (which shined compared to other Flux implementations) and later with redux-saga and with cycle.js. We don't know a lot about Elm. ["functional" in quotes, we know there's much more to actual functional languages]

Having a @ngrx/store package, a @ngrx/store-saga package to pair with sounds a lot nice, and would instantly click in mind of people acquainted with react/redux and coming to visit the angular2 side of the world. After all, at the moment store-saga can only work with store, right?

@ngrx/side-effects sounds good too, and most people playing with redux are aware of the existence pure functions, side effects, side causes, ... and they should have come to know about the need for other libraries to manage the formers (redux-thunk and redux-saga). EDIT Actually I'd argue that term side-effect is more widely known than saga, so after more thoughts it might be preferable.

If you want to play with sounds, maybe @ngrx/side-fx has that x in common with Rx ... just sayin'.

[abdulhaq-e]

I'm working on implementing a version of store-saga that does not use any middleware APIs.

Thanks for the great library, do you have a time schedule for this?

[frederikschubert]

I am throwing my suggestion for a name from gitter into the naming discussion: @ngrx/store-side-effects The store prefix is important because the side effects depend on the store. For side effect orchestration without the store one can use plain rxjs.

[fxck]

I don't like store as a name, it's way too general, so I wouldn't really like any store-some-other-general-word name either... name it something cool.

@ngrx/aftermath @ngrx/backlash @ngrx/reaction

who cares if you won't really be able to tell what does the repo do on the first glance.. you wouldn't know what "redux" or "saga" or "store" or whatever does either, without prior knowledge about this stuff.

[frederikschubert]

I get your point, but till now the ngrx projects have all pretty dry names that describe which part they play in the ngrx world :) router, store, db

[BrainCrumbz]

It looks like the library renaming topic is taking over the initial issue topic (renaming or aliasing some public methods). It could be worth it to move all discussion related to library renaming to a dedicated issue.

[fxck]

Yeah Frederik, because Rob couldn't be arsed to come up with a cool name (and I don't blame him), doesn't mean we have to follow the trend. Talking about store has actually been quite a pita for me, only because of the name, you always have to include the org name (ngrx).

[BrainCrumbz]

Closing as library has been deprecated, and naming issues basically are not meaningful anymore