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

Search: