>migrates the subscription logic from the component/mixin into the decorator. It was not migrating the logic from the component. The example was about getting

>migrates the subscription logic from the component/mixin into the decorator. It was not migrating the logic from the component. The example was about getting rid of a mixin. I think the article even mentions the opposite: “If there is just one component subscribed to this data source, it is fine to embed the subscription logic right into the component. Avoid premature abstractions. >the problem is that everyone else seems to rely on these tools and see them as an integral part of the "React experience" Who is “everyone else”? I think you might be listening to a vocal bubble. As Redux author, I can tell you that it is not in any way essential to React. Some people use it, many people don’t. Solve your problems, don’t just follow what you see in flashy magazines. >I think it would be great if there could be a bit more emphasis on "keeping it simple" in the React tutorials I think this is exactly what React tutorials do: * https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html * https://facebook.github.io/react/docs/thinking-in-react.html https://facebook.github.io/react/docs/thinking-in-react.html We can’t really control what third party tutorials write.