fix: deps bump and react 16.8 compatibility

[vadistic]

Hello, cool tool! :smile:

I've always been on the 'you may not need redux' side, but with hooks api I may give it a try.

So react 16.8 was released few hours ago and your package (as-is) unfortunately throws invariant violations (code-sandbox example does it too :warning: ).

But I really, really wanted to try it so here's a fix^^

• Updated reducer typing, because signature changed
• Added init param to match 16.8 interface, so id param in hooks unfortunately need to go to the fourth place (needs docs update)
• Refactored useContext hooks from useMemo body
• Deps bump to latest

Suggestions:

• Change hooks signature a bit to allow undefined instead of identity (state => state) for third param?
  • Reuse original react typings more because there are cool overloads?

In case anyone googling for a quick fix: yarn add vadistic/reinspect#reinspect-v0.4.3-gitpkg

[vadistic]

I've realised, that I somehow half-assed support for a usecase when somebody would actually want to make use this new init param :grimacing:

The case for inital state worked fine, but now you can properly use initalizer & initializer argument.

Those 3 cases are covered:

// this would work without assertion with added +2 overloads, but it's a bit too tricky for me this morning :)
const [] =  useReducer(myReducer, initalState, undefined as any, 'NAME')

const [] = useReducer(myReducer, initialState, state => state, 'NAME')

const init = (arg) => {
   hello: arg
}

const [] = useReducer(myReducer, 'world', init, 'NAME')

Also:

• Updated useReducer typings to match reacts convention
• Cut useMemo from useReducer, because I could not see how it was not completely superfluous (please review, maybe I'm missing something)

[troch]

@vadistic I can do the signature overloading if you want

[vadistic]

@troch I've managed ^^ Just shuffled them.

Also, added like 3 tests, I was halfway done with them so I thought I might commit.

Btw. I irrationally avoid function keyword, so I rarely overload this way (instead of interface overloading) - any idea why the order of overloads mattered here? I've thought it's just simple declaration merging...

[0xdevalias]

I was wondering.. would it make more sense to use a curried pattern for the useReducer/etc overloads?

eg. useReducer(myId)(normal, params, to, react)

Feels cleaner to me (though obviously a breaking change.. but then it's currently broken anyway.. so..)

Also.. any thoughts on when this might land?

[antoniojps]

Any updates on this? This is package needs this update ASAP since it's currently unusable in my case due to the 3rd param init and ID conflict.

[troch]

Hey @antoniojps, yes will finalise it tonight and release.

[antoniojps]

@troch Thank you for the open source work!