I must say that this release probably wouldn't be possible without community sponsors - both organizations and individual backers.
I'm not saying that money given by the community has helped, but it is a nice incentive to work and a token of appreciation. Somehow the fact alone that people are sending money towards us got me lately back on track, going, writing some code, pushing things forward towards v1 release.
Note that the money is not what you have most valuable to offer for OSS projects - your time is way more valuable. If you want some feature to get implemented, bug to be fixed or just want to help - please reach out to a project's maintainer, maybe ask for pointers about code internals so you can start working easier. OSS is done by regular people like you and most projects' code is not magic, everything can be figured out and you can get comfortable with it.
Maintaining a popular project (over 10k ⭐️⭐️⭐️!) is not an easy task to do. Truth to be told you do not even have to write code to get exhausted. Answering issues, replying to people's demands etc is time and energy consuming.
I'd want to think that at least in those areas I've maintained the package well - nearly every question gets answered and it gets answered within days. I've helped people fix their broken code, I've suggested how their apps can be structured, how to solve particular problems.
However GitHub is not really a place where (most of such) questions should be asked. Whenever you consider asking a question on any project's GitHub, please consider if it is the right place to ask. There are many places you can get help from the community, such as obviously StackOverflow. In terms of redux-saga additionally you can reach out to the community on our gitter channel and redux-saga reactiflux's channel.
New:
multicastChannel
- no buffering, notify all pending takers,multicastChannel#take(cb, matcher = matchers.wildard)
- support for
yield take(multicastChannel, pattern)
- internal
stdChannel
got reworked to be a singleton object (it is wrappedmulticastChannel
's instance'), also it is an exported API to support newrunSaga
's signature - this should also result in being a small perf boost effectMiddlewares
- useful especially for testing, you can intercept/hijack any effect and resolve it on your own - passing it very redux-style to the next middleware (last beingredux-saga
itself). How it might be used can be checked here. Many thanks to @eloytoro for this feature
Breaking changes:
channel
andactionChannel
have default buffer ofbuffers.expanding()
- errors thrown during
put
execution are no longer caught and swallowed, you need to catch them manually eventChannel
does no longer acceptmatcher
argument - it was a hacky way to support previous implementation ofstdChannel
- exported util of
arrayOfDeffered
got renamed to the correctarrayOfDeferred
- internal util of
sym
tries to useSymbol
if it's available, this mainly breaks effects' "shape" - types no longer are simple strings, although no code should make any assumptions about effects' shape anyway - removed some deprecated APIs -
takeEvery
,takeLatest
,throttle
from theredux-saga
entry point (they are and were importable fromredux-saga/effects
),takem
,put.sync
and executing array of effects, there is explicit API for this for already some time -all
effect - changed API of
runSaga
- it no longer acceptssubscribe
option, you should create a channel (preferablystdChannel
), pass it aschannel
argument to therunSaga
API and communicate with through it withtake
andput
methods - most runtime type checks got hidden behing development checks, inputs might not be validated in production (failed validation resulted in error being thrown anyway)
task.done
getter was changed to betask.toPromise
methodchannel
s private getters (__takers__
and__closed__
) got removed
Bug fixes:
- keeping single
stdChannel
in the internals allowed to fix 2 bugs with missed actions (see #707 and #1146), cc @gajus
Internals:
- We have started to use babel@7-beta, hopefully it won't break anything. I've investigated differences between outputs and everything seems to be ok, but you never know ;) This should result in a little bit smaller and a little bit more performant code.