171–180 of 205 posts
React and SPAs Considered Harmful
I keep seeing dependency bloat, over-engineering, unnecessary complexity, all with SPAs not providing the basic things Django/Flask do easily. A good explanation here:
https://medium.com/@wob/the-sad-state-of-web-development-160...
If you're going to use React, use it on one page don't make your whole site/app a single page app.
Earlier quoted context omitted.
I had an impression, that React community (not the authors) considers Redux as an best-practice. My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.
I can't speak for the community as I've been using React/Flux for under a year, but I think that Redux and other Fluxes serve a very different role from component state, and using Redux/Flux to store all your state will cause problems with both performance and code complexity. Redux manages the state of your application as a whole. But individual pieces within the page have no reason to know about the page state. Lik…
Earlier quoted context omitted.
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 ever…
> 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.
Earlier quoted context omitted.
I find that inheritence allows me to save a ton of code, but using it widely does mean you need the ability to refactor, which isn't hard in Java or C#, but can be more of a pain in languages like Ruby.
inheritance is very hard to comprehend at a later date, traversing though sub/super class hierarchy, overrides and super calls is incredibly painful. You often end up with a subclass that may be thousands of lines in length if you consider it's flattened definition.
Also, most modern IDE's have a "Find Declaration" or something similar that allows very simple traversal of class hierarchies. And the help systems are built to allow for easy navigation of the hierarchy so that you can visualize the inheritance paths.
Earlier quoted context omitted.
I would add that there seems to be a push against inheritance in general with UI components in the frontend web app world. React clearly is designed against using it, and same thing with Angular 2 (inheritance does not play well with decorators, which are metadata on specific component classes). I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level,…
> I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally. Composition has the exact same problem in this respect. * Object A * Object B * Object C * Object…
In React, “composition” means has a very specific meaning: it’s putting components into components. It has very little to do with object composition because in React component instances almost never “talk” to each other. They don’t call methods on each other.
React component model is much closer to functional composition which doesn’t suffer from the drawbacks you describe.
Earlier quoted context omitted.
>I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. This is indeed opposition to inheritance in general, precisely because we tried it, and it doesn’t work great in React apps. React has a strong composition model that does not need inheritance. https://discuss.reactjs.org/t/best-practices-for-extending-s... Of course you are free to us…
This is incredibly unfortunate. I feel like this attitude will turn off and hamper a lot of potential users. It smacks of functional proselytizing and it is not appreciated.
I kindddd of feel this way about the "global" context as well, but it's one of those sketchy-yet-handy things haha. Though beyond react-router and redux using it I haven't touched it personally.
Earlier quoted context omitted.
Could you expand on string refs as an anti-pattern?
I'd like an answer to this as well. I've only ever needed string refs, and the callback refs are noisy. I can see where the React team may not want to support both, but are string refs actually bad in some way?
1. String refs are not composable. A wrapping component can’t “snoop” on a ref to a child if it already has an existing string ref. On the other hand, callback refs don’t have a single owner, so you can always compose them.
2. String refs don’t work with static analysis like Flow. Flow can’t guess the magic that framework does to make the string ref “appear” on `this.refs`, as well as its type (which could be different). Callback refs are friendlier to static analysis.
3. The owner for a string ref is determined by the currently executing component. This means that with a common “render callback” pattern (e.g. ``), the wrong component will own the ref (it will end up on `DataTable` instead of your component defining `renderRow`).
4. String refs force React to keep track of currently executing component. This is problematic because it makes `react` module stateful, and thus causes weird errors when `react` module is duplicated in the bundle.
This is why we want to move away from them in favor of callback refs that solve all those problems.
Earlier quoted context omitted.
I think you are confusing React with Redux. They are two very different things. You can use them together but Redux is not the “default” way of using React. >But it is the first principle of Redux Redux is a very opinionated library and it is not related to React in any way. React does not officially endorse Redux. If (and that’s a big if!) React patterns don’t scale for you or if you personally prefer Redux to them,…
Dan, First, thank you for all you do. Huge fan, and you're an asset to the community. One question I have is around this quote: > Learn React first and try to use it. If you have issues related to state or if you’re just curious, you can also learn Redux to compare their approaches. I tried to go down this route with a new employee who I've positioned on a React project (mostly as means of exploration + learning in b…