RFC - Remove all current binding functions except for Hooks about redux-zero HOT 10 OPEN

Hey @makinde, thanks for the feedback.

No, classes don't support hooks. So the reason why I want to go all-in into hooks only API is:

1. That's where React itself is going
2. I don't think that having two ways of doing the same thing is beneficial. Because you'll have more API to learn, more code to maintain and bigger bundle size

I'm already building some experiments to drop support with Connect/connect and go all-in into hooks. And maybe even rebranding the project.

from redux-zero.

@Kiho @leobetosouza @malbernaz @emilianox @d3x7r0

from redux-zero.

i dont have any opinion about it. i'm almost 2 years without using the lib.

from redux-zero.

I've been away from working on much js for the last 6 months or so, so I haven't had much time to stress test the hooks but I think re-focusing on hooks is a good idea. Of course I may be biased since I'm hooked on hooks (pun 100% intended).

Anyway I'm not sure removing the Connect HOC is necessary. It would be relatively simple to refactor them to use Hooks I think.

const connect = ({ mapToProps, actions }) => (Component) => (props) => {
  const selected = useSelector(mapToProps)

  for (const [name, action] of Object.values(actions)) {
    selected[name] = useAction(action)
  }

  return <Component {...props} {...selected} />
}

(untested, back of the napkin implementation).

from redux-zero.

Is a great idea, the only thing I thinking of is not breaking back-compatibility
Maybe a non-hook mode?
Or at least a breaking code warning in the update

from redux-zero.

@leobetosouza thank you for your candid feedback

@d3x7r0 how are you using useAction with async operators? The only way I could was to do this:

const { setState } = useStore();

const incrementAsync = useAction(({ count }) => {
  setTimeout(() => {
    setState({ count: count + 1 });
  }, 1000);
});

But I had some typing errors (when I tried using it with TypeScript).

@emilianox that makes sense as well. But to be honest, people are already getting those warnings if they're using connect or Connect with React >= 16.2.0. My idea was to ship a redux-zero version 6.0.0 without those functions, only focused on hooks.

And maybe even rebranding the name, since we won't have anything to redux anymore, to something else.

from redux-zero.

@matheusml wouldn't the action still support returning a promise for async tasks? You would still do something like your example if you needed to increment a loading counter for example but for simple things it should work no?

const incrementAsync = useAction(({ count }) => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve({ count: count + 1 });
    }, 1000);
  })
});

Anyway I was never very happy with the useAction hook I'll admit. It feels like the function should get the store as a param at the very least but I haven't actually worked with the lib for 6 months or so like I mentioned before.

from redux-zero.

The issue with this current API (the useAction with async), is that you can't do stuff like this:

const actions = (store) => ({
  getUsers: state => {
    store.setState({ loading: true });
    fetchUsers().then(users => {
      store.setState({ users, loading: false });
    });
  }
});

Well, at least I tried and couldn't do it.

from redux-zero.

@matheusml interesting idea.

I use both hooks and the connect function right now. The connect function is nice for when I have a few bits of data that I need to pull out from state. Using useSelector I have to have a separate call for each bit of data I want.

I also find it nice that the general API here is similar to redux. When other collaborate on my project, if they have used redux before, they understand mostly how to use redux-zero. If the paths diverge, that advantage goes away.

It is a bit odd to have two ways to do the same things, but I’d really encourage both to remain if possible. Also (I’m not sure) do class components support hooks?

from redux-zero.

Thanks for responding. You should definitely feel empowered to direct things as you see best.

I’ll just quickly highlight some of what you gain with the current “redux-like” branding and messaging. Because I know that this library is supposed to be like redux, I can depend on their docs. For instance, I’m trying to learn middleware in redux-zero right now. The docs are...brief, to say the least. But because it is so similar to the redux concept, I can rely on the tons of documents and blog posts about the topic.

Just something to keep in mind as you consider diverging from redux in the future. Thanks for all the hard work on the tool!

from redux-zero.