API Portability

[jamesplease]

I like that this lib, and its API, draws such strong inspiration from ReasonReact, with the inclusion of functions like Update and NoUpdate. A side-effect of those specific functions is that it reduces the portability of the reducers that authors write.

Because this lib has a hard dependency on React, any reducer that you write using Update/etc. must also require React.

One of the things I liked about React's reducer API is that the reducers themselves are agnostic to React. It is pretty cool to write a reducer one time and to be able to use it in different contexts.

Technically it's possible to do that with this library as well by explicitly returning an object with the shape:

{
  newState: { ... },
  newEffects: [ ... ]
}

but it's undocumented, so I'm thinking of it as an internal API.

Questions for you:

• do you think there's any value in API portability?
• if so, would you consider the return value of Update, etc. to be public API?

The motivation for this issue is that I'm writing reducers that I plan to use both in and outside of React apps, and i want to use the useReducersWithSideEffects architecture in both. In the React world I planned to use this library to integrate it into my app, and then I planned to write a vanilla JS version for outside of React.

[conorhastings]

I'd consider the return value of Update public, yes. I've also considered treating a pojo return the same way a . call tto update is treated, any opinion?

[jamesplease]

any opinion?

Agreed! I like it that way.

I'll go ahead and close this out then. I think what's happening over in #11 will make it "feel" more public once all of the naming is aligned. I might also PR a README update that mentions it if you're open to that idea.

[conorhastings]

ya any readme change that seems like it would help go for it, can be hard for me to get the 10,000 foot view when writing the code