HN Explorer

5 comments

[ 4.4 ms ] story [ 20.8 ms ] thread
ricardobeat
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.
vonseel
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.

johnsimer
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

davidjnelson
I mean, you can still dispatch when you get the data from the hook that wraps useeffect.
davidjnelson
That’s a lot of code for very little functionality.