Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packages like `redux-thunk` and `reselect` as well.

We've updated the Redux core docs tutorials to teach RTK as the default [1] [2], and have examples of migrating existing Redux logic to use RTK [3].

As for the CRA aspect: I still don't really understand why some people refer to CRA as "bloated". It has all the standard pieces that have been used in the React ecosystem for years: Webpack for bundling, Babel for transpilation, Jest for testing, and ESLint for linting, and all with a very reasonable default configuration that has had thousands of hours of effort to deal with edge cases.

I'm not saying that CRA is _perfect_. The maintenance has been spotty lately, it's taken a very long time for the Webpack 5 branch to get close to release, and I'd love to see CRA adopt tools like SWC or CRA to speed up builds. But given the problems in the ecosystem before CRA, it's done exactly what it was supposed to: provided a single command to set up a new React app with good build defaults.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/quick-start

[2] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[3] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...



> It has all the standard pieces that have been used in the React ecosystem for years

Yes, that's the problem. It has ALL the pieces, whether you are using them, whether you understand them or not. For example, most projects will use either babel typescript. CRA? It has both and extra logic to switch between the two.

I feel like a better approach would be / have been an "open book" config where there is minimal starting point and it teaches you how to add the extra bits you want/need. That way it would be kept as simple as possible, and people using CRA would actually understand the tools they are using.


I'm genuinely curious - what difference does it make to you, the end user, if CRA has that extra logic internally? You won't see any of it unless you intentionally eject, and all it really is is some checks in the Webpack config file and the startup process.




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

Search: