3 ms·

Thanks for clarifying this! Maybe I misunderstood the example in the article that migrates the subscription logic from the component/mixin into the decorator. T

Thanks for clarifying this! Maybe I misunderstood the example in the article that migrates the subscription logic from the component/mixin into the decorator. This was what made me question whether this will be more efficient/scalable than using the Mixin approach, as there is also some indirection here. Concerning the whole Redux issue: Yes, of course I can -and do- use React without it, but the problem is that everyone else seems to rely on these tools and see them as an integral part of the "React experience". I find this problematic as it makes many components less portable, as they are bound to a given router / state loading paradigm. I think it would be great if there could be a bit more emphasis on "keeping it simple" in the React tutorials, as I see a lot of (often unneeded) complexity popping up in the frontend world, and I think this will cause a lot of issues in the future.

moogleii 10y ago
> I find this problematic as it makes many components less portable, as they are bound to a given router / state loading paradigm. Interesting, I find if you "reduxify" everything, even the top most component becomes somewhat dumb and agnostic. With react-redux, it won't even be aware of the dispatcher.
- methyl 10y ago
  Only if you have just one point where you _connect_ your components. If there are some containers deep in the tree then suddenly all your application is somehow tied to Redux. I've seen such recommendations from Dan to use connect often, but I find this problem a bit disturbing and not sure how (and if) to mitigate that.
danabramov 10y ago
>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.
- ThePhysicist 10y ago
  Thanks again for clarifying, I don't want to criticize the work of the React authors or the community (which is outstanding), I'm just voicing what I observe from my "vocal bubble". Maybe I really spend too much time on HN :D
  - danabramov 10y ago
    Yea, no problem. HN can be super misleading. I suggest to build apps and learn from the experience instead. ;-)

moogleii 10y ago

> I find this problematic as it makes many components less portable, as they are bound to a given router / state loading paradigm. Interesting, I find if you "reduxify" everything, even the top most component becomes somewhat dumb and agnostic. With react-redux, it won't even be aware of the dispatcher.

methyl 10y ago
Only if you have just one point where you _connect_ your components. If there are some containers deep in the tree then suddenly all your application is somehow tied to Redux. I've seen such recommendations from Dan to use connect often, but I find this problem a bit disturbing and not sure how (and if) to mitigate that.

danabramov 10y ago

>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.

ThePhysicist 10y ago
Thanks again for clarifying, I don't want to criticize the work of the React authors or the community (which is outstanding), I'm just voicing what I observe from my "vocal bubble". Maybe I really spend too much time on HN :D
- danabramov 10y ago
  Yea, no problem. HN can be super misleading. I suggest to build apps and learn from the experience instead. ;-)