Would you like to share any reasons you believe that? Or at least which part you find unnecessarily complicated?
React exists out of a need to organize a complex system of interactions. Unless you understand what it's like to have to reel that sort of thing in, it's not going to be easy to wrap your head around quickly.
Have you thought about using MobX instead? I think Redux's "complications" stem from guiding you towards a certain set of principles and ways of coding without giving you the tools to commit to those principles and ways of coding. Particularly, the way you compose reducers and the way you expose actions is manual and very boilerplate-ish.
Mark Erikson hosts a wonderful page full of redux ecosystem links, and here you can see all the tools to allow you to write and compose reducers - https://github.com/markerikson/redux-ecosystem-links/blob/ma... so clearly there was something missing there.
Redux as an idea I found very simple yet interesting. Watching Dan Abramov's series on building a Redux-lite from scratch helped changed my way of approaching how I build web apps.
However, using Redux in the mundane, daily sense was riddled with little practical niggles that were never really answered by the fairly minimalistic library, so I ended up with a kind of feeling that Redux kind of required me to "know" how to write good code before I commit to using it...
Meanwhile MobX seems to map to my mental model and all the modes of "mutation" that I'm already used to and have experience in, while also essentially introducing the same ideas as Redux.
I'm currently in the process of migrating a decently large React app from poorly written React/Flux to (hopefully) better written React/Redux, and I'm definitely feeling the lack of...useful examples. A ToDo list or showing lists of users from Github just doesn't cover the realistic complex problems well. Thus, when I encounter one of those problems, and Google fails me, I have to take a stab at it...and likely recreate the not-best-architectures of those that have done the same before me.
I'm still happy with Redux so far - the patterns it encourages is at least an improvement over the code from before, but I can't shake the the feeling that there are basic mistakes I'm making because I only have a handful of best practices goals.
Hi. My React/Redux links list [0] has a category for Redux architecture and best practices [1], with a ton of good info.
Also, the "Redux Tutorials" category has a "Project-Based Tutorials" section [2], which points to a number of tutorials that try to build _something_ in the process of teaching. Many of those tutorials are quite a bit more complex than yet another TodoMVC example. To pick out two specific examples:
- "Building a Simple CRUD App with React + Redux" [3] is an 8-part series that demonstrates building a CRUD app, including routing, AJAX calls, and the various CRUD aspect
- My own "Practical Redux" series [4] tries to demonstrate a number of intermediate to advanced React and Redux concepts in the context of a semi-meaningful-ish sample app.
Finally, my Redux addons list has a section listing a number of interesting React+Redux apps [5], both purpose-built examples and real world projects.
Hopefully that gives you some useful examples to work with. I'd also encourage you to drop by the Reactiflux chat channels on Discord to ask questions and get feedback, at https://www.reactiflux.com . Feel free to ping me on there!
In theory I like the basic ideas around redux, reducer composition is a very cool idea. However I really hate the implementation, the amount of boiler plate code is just too high.
If I had a nickel for every time I'd heard the "b" word... :)
FWIW, there's quite a few ways to reduce boilerplate with Redux, and you're welcome to use as many of them as you want. Variations on folder structures, action/constant definitions, reusable reducer logic, various abstraction layers... all kinds of stuff.
Would be interested to hear which particular pain points bother you.
Hey, somebody actually referenced my Redux addons list! Yay! :)
Yeah, there's a great quote someone posted in a Redux issue a couple months back that summarizes things well [0]:
> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.
So, there's a couple ways to think about things. One is that Redux is a very simple pattern that provides just enough structure to point you in a direction, and lets you figure out what specific approaches work best for your own situation. Another is that Redux is too generic, and doesn't provide enough guidance or built-in stuff for various use cases.
I've been one of Redux's maintainers since last summer, and I've definitely seen certain requests pop up repeatedly. For example, we frequently have issues or PRs filed asking if we can modify `combineReducers` to have built-in support for iterating over and updating Immutable.js Maps and Lists. We've also had requests for `cR` to pass down the root state as a third arg to reducers by default, or something similar.
These aren't _bad_ requests, and there's clearly some valid use cases there. However, one of the key principles of Redux is that _reducer logic is just functions_. The standard answer we've given for the most part is just that "`combineReducers` is only intended for the most common and basic use case, but you should feel free to write your own reducer logic for your own use case". So, in that sense, that large list of reducer-related utilities is actually a _good_ thing, because it means people _are_ building pieces that suit their needs.
FWIW, I personally have made a major effort to add documentation and write tutorials on a lot of the more practical issues Redux users face. I wrote the FAQ [1] and "Structuring Reducers" [2] sections for the docs, and have been writing a blog series called "Practical Redux" [3] that's intended to demonstrate some intermediate to advanced concepts in the context of a sample app.
If you have any particular pain points that you feel the docs do not currently address very well, please file an issue or a PR. I'm ALWAYS happy to work with anyone who wants to improve the docs.
As for Redux vs MobX, Preethi Kasireddy's presentation today was a FANTASTIC comparison of the relative strengths, weaknesses, tradeoffs, and use cases for each of them. I highly recommend that people check it out as soon as the ReactConf recordings are posted online. Also, my React/Redux links list [4] has a section that links to several other good MobX/Redux comparisons as well [5].
Hi! Got a couple pointers for you. First, my React/Redux links list [0] has links to many Redux tutorials of various kinds, as well as dozens of articles on Redux architecture, best practices, and useful techniques.
Second, if you've got questions, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. I'm an admin, and hang out there evenings US time, but there's always plenty of people happy to talk and answer questions. The invite link is at https://www.reactiflux.com .
Please feel free to ping me there if there's anything I can do to help!
This argument has been applied to virtually every framework or library at some point; the points and counterpoints rarely change and the result is inevitably to use right tool for your type AND scale of problem.
FWIW React's purpose is the opposite of what you said; it aims to make complex UI tasks simple by allowing you to compartmentalize your UI into isolated components.
If your UI isn't that complex or your application has very little state to manage then I could see how React would be overkill.
For anyone interested in more details about React Fiber, the recommended links in [0] provide a great jumping-off point. For many apps, especially ones that render large amounts of data to a screen and haven't done (or can't do) much optimizing with componentShouldUpdate, it will likely be an almost-seamless drop-in upgrade that will make things feel truly more "snappy." A video (of a demanding stress test) is worth a million words: [1]. And it's coming soon: [2]
React Fiber will make an impact, but it's an incremental upgrade so don't be afraid to start a new project now—there'll be an easy upgrade path when React 16 is out!
(Facebook has tens of thousands of components, so you can be sure that'll happen)
Cheng Lou works on ReasonML and is speaking tomorrow at 4:30PM PST. Talk description:
> What is a piece of code? What is a library, a tool, a platform and a language? Based on my last talk on the spectrum of abstraction, this talk explores the daily concerns and the meta-concerns of writing code, and how our new effort, Reason, relates to them.
I think it's not that he "doesn't get to talk about tech". I think women and minorities just generally are more likely to talk about diversity because it affects them more directly and thus if you pick a diversity talk at random the speaker is more likely to fall in one of those categories -- whereas because they are the minority in tech, a tech talk picked at random will likely be by a white male speaker.
IMO it'd make sense to counterbalance this bias just like the bias for speakers in general: I'd love to hear more women and minorities talk about tech and more "straight white cis-males" talk about diversity but I'm sure someone's bound to complain if "the diversity talk" is given by a straight white cis-man because reasons[0].
I've actually noticed the "wrong narrative" you decry myself: at last year's React Conf while browsing the videos I instinctively guessed who was going to give the diversity talk by looking at the speaker. I was aware of my bias but I sadly saw it affirmed.
You don't fix the problem by talking about it. You fix it by living it. Sadly right now there don't seem to be enough high quality minority speakers to solve this without running into the "all confs sound the same" problem (more than they do already).
It's complicated.
[0]: Counterpoint: getify seems to be widely accepted as a diversity speaker but I'm not sure whether he's held talks exclusively about diversity at conferences where there weren't also women or minorities also giving diversity talks.
Adding to the AWS Lambda + React talk; if anybody is looking for a more detailed Serverless + React.js tutorial, we've put together - http://serverless-stack.com
It goes into detail on how to use AWS and React.js to handle user authentication, file uploads, and securing your serverless backend. We go through step-by-step building a simple note taking app with detailed screenshots and code samples.
48 comments
[ 88.5 ms ] story [ 1245 ms ] threadReact exists out of a need to organize a complex system of interactions. Unless you understand what it's like to have to reel that sort of thing in, it's not going to be easy to wrap your head around quickly.
Coming from ExtJS and Ember, React felt rather simple.
But Redux is a whole nother story :(
Mark Erikson hosts a wonderful page full of redux ecosystem links, and here you can see all the tools to allow you to write and compose reducers - https://github.com/markerikson/redux-ecosystem-links/blob/ma... so clearly there was something missing there.
Redux as an idea I found very simple yet interesting. Watching Dan Abramov's series on building a Redux-lite from scratch helped changed my way of approaching how I build web apps.
However, using Redux in the mundane, daily sense was riddled with little practical niggles that were never really answered by the fairly minimalistic library, so I ended up with a kind of feeling that Redux kind of required me to "know" how to write good code before I commit to using it...
Meanwhile MobX seems to map to my mental model and all the modes of "mutation" that I'm already used to and have experience in, while also essentially introducing the same ideas as Redux.
Mobx also frees you from the "Redux architecture", which I found to be difficult and contrived...
I'm still happy with Redux so far - the patterns it encourages is at least an improvement over the code from before, but I can't shake the the feeling that there are basic mistakes I'm making because I only have a handful of best practices goals.
Also, the "Redux Tutorials" category has a "Project-Based Tutorials" section [2], which points to a number of tutorials that try to build _something_ in the process of teaching. Many of those tutorials are quite a bit more complex than yet another TodoMVC example. To pick out two specific examples:
- "Building a Simple CRUD App with React + Redux" [3] is an 8-part series that demonstrates building a CRUD app, including routing, AJAX calls, and the various CRUD aspect
- My own "Practical Redux" series [4] tries to demonstrate a number of intermediate to advanced React and Redux concepts in the context of a semi-meaningful-ish sample app.
Finally, my Redux addons list has a section listing a number of interesting React+Redux apps [5], both purpose-built examples and real world projects.
Hopefully that gives you some useful examples to work with. I'd also encourage you to drop by the Reactiflux chat channels on Discord to ask questions and get feedback, at https://www.reactiflux.com . Feel free to ping me on there!
[0] https://github.com/markerikson/react-redux-links
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] https://github.com/markerikson/react-redux-links/blob/master...
[3] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
[4] http://blog.isquaredsoftware.com/series/practical-redux
[5] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
FWIW, there's quite a few ways to reduce boilerplate with Redux, and you're welcome to use as many of them as you want. Variations on folder structures, action/constant definitions, reusable reducer logic, various abstraction layers... all kinds of stuff.
Would be interested to hear which particular pain points bother you.
Yeah, there's a great quote someone posted in a Redux issue a couple months back that summarizes things well [0]:
> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.
So, there's a couple ways to think about things. One is that Redux is a very simple pattern that provides just enough structure to point you in a direction, and lets you figure out what specific approaches work best for your own situation. Another is that Redux is too generic, and doesn't provide enough guidance or built-in stuff for various use cases.
I've been one of Redux's maintainers since last summer, and I've definitely seen certain requests pop up repeatedly. For example, we frequently have issues or PRs filed asking if we can modify `combineReducers` to have built-in support for iterating over and updating Immutable.js Maps and Lists. We've also had requests for `cR` to pass down the root state as a third arg to reducers by default, or something similar.
These aren't _bad_ requests, and there's clearly some valid use cases there. However, one of the key principles of Redux is that _reducer logic is just functions_. The standard answer we've given for the most part is just that "`combineReducers` is only intended for the most common and basic use case, but you should feel free to write your own reducer logic for your own use case". So, in that sense, that large list of reducer-related utilities is actually a _good_ thing, because it means people _are_ building pieces that suit their needs.
FWIW, I personally have made a major effort to add documentation and write tutorials on a lot of the more practical issues Redux users face. I wrote the FAQ [1] and "Structuring Reducers" [2] sections for the docs, and have been writing a blog series called "Practical Redux" [3] that's intended to demonstrate some intermediate to advanced concepts in the context of a sample app.
If you have any particular pain points that you feel the docs do not currently address very well, please file an issue or a PR. I'm ALWAYS happy to work with anyone who wants to improve the docs.
As for Redux vs MobX, Preethi Kasireddy's presentation today was a FANTASTIC comparison of the relative strengths, weaknesses, tradeoffs, and use cases for each of them. I highly recommend that people check it out as soon as the ReactConf recordings are posted online. Also, my React/Redux links list [4] has a section that links to several other good MobX/Redux comparisons as well [5].
[0] https://github.com/reactjs/redux/issues/775#issuecomment-257...
[1] http://redux.js.org/docs/FAQ.html
[2] http://redux.js.org/docs/recipes/StructuringReducers.html
[3] http://blog.isquaredsoftware.com/series/practical-redux
[4] https://github.com/markerikson/react-redux-links
[5] https://github.com/markerikson/react-redux-links/blob/master...
Second, if you've got questions, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. I'm an admin, and hang out there evenings US time, but there's always plenty of people happy to talk and answer questions. The invite link is at https://www.reactiflux.com .
Please feel free to ping me there if there's anything I can do to help!
[0] https://github.com/markerikson/react-redux-links
FWIW React's purpose is the opposite of what you said; it aims to make complex UI tasks simple by allowing you to compartmentalize your UI into isolated components.
If your UI isn't that complex or your application has very little state to manage then I could see how React would be overkill.
Maybe it'll change your mind
Edit: it appears that there is a talk related to TypeScript
That talk appears that it will make the argument for using Flow/Typescript.
[0] https://github.com/facebook/react/issues/7925#issuecomment-2...
[1] https://www.youtube.com/watch?v=Qu_6ItnlDQg
[2] http://isfiberreadyyet.com/
(Facebook has tens of thousands of components, so you can be sure that'll happen)
> What is a piece of code? What is a library, a tool, a platform and a language? Based on my last talk on the spectrum of abstraction, this talk explores the daily concerns and the meta-concerns of writing code, and how our new effort, Reason, relates to them.
I don't think it is deliberate but it perpetuates a wrong narrative.
==
EDIT.
I was inaccurate in this case. See below
When I looked through, I didn't see him. I'm happy I am wrong here.
The stats are still worrying [1]. My greatest joy will be to be continuously wrong on this
[1] http://oonwoye.com/2015/10/15/where-are-the-black-tech-found...
IMO it'd make sense to counterbalance this bias just like the bias for speakers in general: I'd love to hear more women and minorities talk about tech and more "straight white cis-males" talk about diversity but I'm sure someone's bound to complain if "the diversity talk" is given by a straight white cis-man because reasons[0].
I've actually noticed the "wrong narrative" you decry myself: at last year's React Conf while browsing the videos I instinctively guessed who was going to give the diversity talk by looking at the speaker. I was aware of my bias but I sadly saw it affirmed.
You don't fix the problem by talking about it. You fix it by living it. Sadly right now there don't seem to be enough high quality minority speakers to solve this without running into the "all confs sound the same" problem (more than they do already).
It's complicated.
[0]: Counterpoint: getify seems to be widely accepted as a diversity speaker but I'm not sure whether he's held talks exclusively about diversity at conferences where there weren't also women or minorities also giving diversity talks.
It goes into detail on how to use AWS and React.js to handle user authentication, file uploads, and securing your serverless backend. We go through step-by-step building a simple note taking app with detailed screenshots and code samples.