To be honest, this article scares me from using react/redux, because the author don't know how types works.
(I can't be the only one)
(I can't be the only one)
Redux is a simple library that you can read through in a few minutes. It's working great for hundreds of thousands of users. Why would Dan's background scare you off from using it?
As for React, there's more than just Dan on the React team. (In particular, Seb Markbage is an incredibly deep thinker, and the rest of the team is great too).
"and I already forgot most of C#"
It scares me off for the same reason that hundreds of thousands of people use dynamic languages, and I still believe that this is far from being a good idea.
The same way that hundreds of millions of people believe in god, and I still think this is absurd.
React itself represents a shift in webdev thought where, instead of desperately trying to establish itself as a "respectable" programming field (see: any Google web technology), it instead focuses on being as accessible as possible and embraces the populist nature of the web. This article is just an extension of that ideology.
And, as you've indicated, anyone who would be horrified by that ideology probably is already horrified by the web to begin with.
I’ve been doing full time JS with some Ruby for the past 5 years. I doubt I could write anything more than “Hello world” in C# without a lot of Googling.
"I understand the concept of types and can read annotations but I’ve never written it. The few times I tried, I ran into difficulties."
I looked his github, and his only C# experience seems to be a tictactoe made in 2014.
I’ve worked on C# codebases professionally for about four years. They’re not open source because half of that time I worked on enterprise software (ASP .NET MVC, Entity Framework, NHibernate) and another half was a closed source product (Xamarin aka MonoTouch, Rx). Prior to that I worked a little on an open source static analysis tool (Gendarme) using Mono Cecil.
Prior to that I was moderating the .NET section on one of the largest Russian programming forums and translated documents like LINQ Overview when they came out. I also have a silver C# badge on StackOverflow. (https://stackoverflow.com/help/badges/39/c-sharp?userid=4581...)
I know how types work. My remark was that I haven’t worked with C# for about four years. I’m not aware of changes between versions 5 and 9, and might have forgotten some of the C# syntax for things like lambdas, having worked a lot with JS since then.
I’ve mentored a few junior devs in my day, and this kind of thing would have been really helpful to encourage them to keep pushing.
> The same way that hundreds of millions of people believe in god, and I still think this is absurd.
Well, that takes the idea of a 'programming language holy war' to a very literal place.
Maybe my React needs are minimal, but I tried following a tutorial using React and Redux and I was immensely confused. Once I struck out on my own and ditched Redux for just straight React, everything became so much clearer and simpler.
We're currently planning a revamp of the Redux docs. I'd really appreciate any feedback on what things caused problems, so we can know how to make the docs better.
Feel free to comment here, or ping me on Twitter or in the Reactiflux chat channels. I've also got a survey open asking for suggestions on docs structuring: https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYM...
Also, fwiw, you may be interested in my suggested resources for learning Redux:
https://blog.isquaredsoftware.com/2017/12/blogged-answers-le...
I haven't looked at the docs in a while but I'm not sure that's where the big problem lies. The hard thing about Redux is that you need to "get" the core concepts (not that complex), and how they interplay with how (and when) React renders component subtrees (very complex - this requires a new understanding of react you didn't need before).
After you learn React and finally "get" it you definitely won't get Redux. Not because of Redux perse, but because the way you structure your application is so different. After that you'll encounter more subjective questions like do we put this (semi localized) state in Redux? And there are no right answers anymore, just opinions.
Also the boilerplate doesn't help.
As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on).
As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that?
FWIW, we have a new package called `redux-starter-kit`, which is specifically intended to help simplify several common Redux use cases. It includes utilities that help with store setup, reducer definitions, immutable update logic, and even creating entire "slices" of state automatically without having to write any action types or action creators yourself. I'd encourage everyone to try it out, and let us know how much it helps improve your apps and what else ought to be included:
Those new sections sound awesome! Kudos for thinking about adding them to the docs.
https://github.com/reduxjs/redux/issues/2590
https://github.com/reduxjs/redux/issues/3313
I'm particularly hoping to do some brainstorming about the revamped docs structure and content over the next couple days.
As stated before I haven't done a big JS project for about a year now. In the last project I did we used redux in a create-react-app. At the time the best practice was creating presentational and container components[1].
The biggest boilerplate was:
- Whenever we added a react component (presentational) we would need to create a container component to wrap it in, this would always result in ~20 or basically the same lines (in our project we did things pretty verbose, so we didn't have a HoC or whatever people use).
- "immutable update logic", reducing deeply nested objects is a pain an error prone (using es6 spread or Object.assign), I've heard about some libraries that can help with this, but we didn't use anything at the time).
> FWIW, we have a new package called `redux-starter-kit`
I am most definitely going to use this for an upcoming project!
[1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd like to have the tutorials and examples switch from a "folder-by-type" approach to either a "feature folder" or even a "ducks" approach, and maybe even cut down on having separate action constant variables. There's valid reasons to do things in multiple files, but it's also not _necessary_, and I want to simplify things.
Yes, I totally agree immutable update logic is a pain to write and write correctly, which is why Immer is awesome, and why the starter kit uses Immer internally. My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win.
Please let me know how well it works for you, and if you've got any other suggestions for what it should include!
> My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win.
It's only a win since we decided that "mutation is bad" and we had to do spread notation gymnastics in all our es-2025 code that we are compiling to es5 anyway. From an abstraction point of view this is how I feel consensus about state management changed over time in the frontend world (or the part/frameworks I was involved in):
- 2010: jQuery will help you update the DOM anywhere (looking at IE6) - but you have to solve state yourself. A deeply nested object attached at `window` was considered best practice.
- 2012: We need to manage state properly, here is a nice Backbone "model" class: pass it a schema and use getters/setters to update so you can glue state change events to your view logic.
- 2014: Angular (first version) is great! Don't worry about managing your state yourself, just attach whatever you want to $scope and we will simply use dirty checking to check everything whenever something changes.
- 2015: React uses a vdom which behaves similar: change whatever you want and keep rendering it and React will figure out what actually changed. And for your state we made this flux thing which you implement as a bunch of different data stores (in my mind similar to backbone models except they only go "one way").
- 2016 (redux): here is a single store that also flows one way. Oh yea you need to do everything functional and you can't mutate any objects anymore or things will break. These 20 lines of code show you how to change the property of object with another property called id with value "x" in a nested list. This is better because it makes diffing faster in the vdom. You have to make sure you never mutate so here is a way to "freeze" your objects which will make sure you don't do this.
- 2017 Immer (I haven't used this yet): We realize it's a pain to change big objects if you can't mutate, so here is a dummy object you can mutate, we will clone it to make sure it's a different object. This is a proxy to the objects that will end up in your store (and exposed to your view layer).
I understand how we got to needing Immer, but it's a solution to a problem we only have because of how frameworks like React figure out what changed (strict equality). But it's too verbose and error prone for us to do manually. React only got designed as it did because too many people got tired of OO style state management. Right now I'm noticing a lot of people are getting tired of the verbosity, boilerplate and complex abstractions that come with doing things the "proper React way" (updating state represented in an object is the main example here, but that whole chain is verbose: you need to create actions you can dispatch, you need to write a reducer to catch those actions and mutate your objects, you need to glue the correct state to each component).
React is great tech, but in a lot of ways it's a counter movement. Countering complexities you get when managing state the OO way. But now it has gotten very complex itself, we now need a solution (immer) introduced by a solution (redux) that was needed to manage state inline with React. In other words, also very complex.
It feels almost as if I took the Backbone code, renamed it and marketed as "a simpler way to manage your UI" I could get a lot of people to switch away from React + redux + immer + immutable + redux-thunk + etc...
The number of new developers has been outstripping the number of old developers in most environments and this has been happening for at least the last 15 years.
Thus, we come back to Richard P. Gabriel's Worse is Better, or at least the essay's focus on the importance of social components of a project[1]. N.B.: not implying Redux is worse than any of the other discussed projects.
Newer generations cannot possibly have the time to go through the history and tradeoffs of various frameworks that used to be extremely popular and the reasons people moved on. Too many previous frameworks and too few posts like what you just wrote. Besides, where to start? It's not like TAOCP is going to have a chronology of Browser UI frameworks.
Instead, the tendency is to leverage the rapidly developing ecosystem and work with the projects that have the largest numbers of stars on github, etc.
If you are a very large well heeled eng. organization with a capability to enforce the use of particular frameworks, it is in your interest to popularize them. You will pay and encourage your engineering org to, among other things they do, market it to the dev. community. If there are enough engineers in your org (say: tens of thousands), you will begin exerting a tremendous concentrated influence on the Open Source community.
At the same time, for everyone else who does notwork inside a 10K+ engineer org, the lack of future maintenance and upgrades presents such a huge downside risk to not using the most popular open source frameworks. The open source community moves so quickly that you run into the risk of being stuck with maintaining the reusable components you plucked from other open source efforts.
The backwards compatibility guarantees are so much lower than what they used to be. The browser world is still figuring out how to link dependencies[2], let alone generate a stack that is stable enough where you don't have to continually update your UI codebase if you want to keep continuing to reuse other people's widget code.
So you tend to stay with the pack. React is the new most popular thing? OK, let's do React. Redux is the new way? OK, Redux. Pick anything else and you risk being stuck with a stack that rapidly loses the ability to interoperate with a huge majority of new Browser UI open source code.
[1] https://en.wikipedia.org/wiki/Worse_is_better
[2] https://medium.com/webpack/the-state-of-javascript-modules-4...
I will admit I did not choose to use Redux, it was part of a tutorial I was following on Udemy. I never got the hang of it, and once I figured out React Native well enough, I quickly scaled back my reliance on Redux. It's made my life a lot easier.
My day job is a technical consultant for a major tech company, and we have meetings to discuss the meeting we're going to have before the meeting. The administrative overhead of Redux reminds me of that in a very bad way. Instead of my Facebook login button calling auth_actions.js which then returns the auth token to auth_reducer.js which then returns the auth token to auth_screen.js (but don't forget to add it to the combineReducers in index.js), I just put the authentication code in 'await doAuth()' inside of the auth_screen.js file. I've never heard a convincing reason as to why I shouldn't do that, even though the tutorial I followed said it's a bad idea.
Were you following Dan’s tutorial on Redux? Because that is a beautifully made tutorial as well. (https://egghead.io/redux)
If you have tried to build a substantially big app with React alone, you will find yourself lost in passing down the props and callbacks and hoisting variables and what not. You definitely need a state management library where you can CRUD from all your React components. Thats where Redux/Mobx comes into picture, unless you want to write a new one.
I agree that Redux needs a lot of boilerplate though.
I can't count the number of hours I've lost to stuff like this.