Hacker News new | past | comments | ask | show | jobs | submit login
Typechecking state transitions in a React/Redux app (javiercasas.com)
10 points by javcasas 3 months ago | hide | past | web | favorite | 5 comments

And this is how you end up with 12 branches in a reducer, 4 in render, 4 state types, 4 action types, 4 action creators, plus the mapDispatchToProps definitions, all to handle a simple network call that could have been:

    const App : React.FunctionComponent = () => {
      const { loading, data, error } = useMagicFetch(...); 
      if (error) return <Error error={error} />;
      if (loading) return <Loader />;

      return <DataList data={data} />;
But then you lose the benefits of serializable / replayable / shared state. Mind you, I've built multiple apps that ended up not too far from this, and am eagerly looking for alternatives.

Lol, that’s a fantastic criticism of redux. I’m also using redux and agree on all points.

I’d be curious what your thoughts are on (off-topic) using something like InversifyJS to accomplish IOC/DI in Typescript? I accidentally went down that rabbit-hole this week before realizing maybe the only thing I’m good at is creating a damn awful mess with overcomplicated frameworks and design patterns.

I use Inversify for a project that has a lot of custom objects/data flow that dont fit in your typical react/redux model.

The learning curve took me a while, but now creating new objects and inserting them into my app doesn't require too much thinking and is nearly bug free

I mean, you can still dispatch when you get the data from the hook that wraps useeffect.

That’s a lot of code for very little functionality.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact