31–40 of 52 posts
How long has React been out? Simple patterns such as component communication are debated, and third-party documentation about them is newsworthy?
Ugh, the dependency injection stuff is just Angular all over again. export default wire(Title, ['title'], function resolve(title) { return { title }; }); Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument…
Angular's DI is my main reason for switching to react. If it becomes standard in react then what?
var enhanceComponent = (Component) =>
class Enhance extends React.Component {
render() {
return (
)
}
};
Ugh, the dependency injection stuff is just Angular all over again. export default wire(Title, ['title'], function resolve(title) { return { title }; }); Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument…
I don't mind DI, in Angular or elsewhere. I'm not sure in what way you think of it as a DSL, or even that it requires tooling. It's a useful pattern in OOP.
foo(X dep) {} vs foo() {X dep = new X()}
It's overused imo but it's fine. The problem comes with DI frameworks like Spring or Angular DI when you start letting the framework tie your code together. This couples you tightly with the framework and can lead to odd situations where the thing you're getting isn't what you're expecting but that's not obvious because the object passing is happening behind a curtain.
Ugh, the dependency injection stuff is just Angular all over again. export default wire(Title, ['title'], function resolve(title) { return { title }; }); Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument…
I don't mind DI, in Angular or elsewhere. I'm not sure in what way you think of it as a DSL, or even that it requires tooling. It's a useful pattern in OOP.
Earlier quoted context omitted.
I started with this tutorial[0] that covers react with no JSX, no Flux, no ES6, and no Webpack. It is just a couple of script includes and normal html/javascript. From that tutorial, I was able to understand exactly what react is . Then I started adding in the other items on top. It's definitely not a boilerplate "site in 5 minutes", but it's also a lot less confusing when trying to learn what's going on underneath t…
This was my first exposure too. Once you're ready to build an app with JSX (probably right after you finish that tutorial and realize that typing React.createElement all over will get painful), check out the new tool Create React App[0] by Dan Abramov and the folks at Facebook. It's an official generator that'll get you going with no build to set up, and a bare minimum of necessary code, basically one step above Hell…
One thing I prefer about Angular is all of these patterns are established and documented by the same people who designed the framework. In React they are distributed among hundreds of blogs and individual github repos, which all debate each other. How long has React been out? Simple patterns such as component communication are debated, and third-party documentation about them is newsworthy?
But, in such an environment, there's no marketplace where ideas can compete and evolve. There's a trade-off where you have to do the hard work of navigating and choosing among competing ideas, but the benefit of React is that you can choose an architecture, today, that isn't a four-year-old snapshot of a small group's idiosyncratic architectural preferences.
Ugh, the dependency injection stuff is just Angular all over again. export default wire(Title, ['title'], function resolve(title) { return { title }; }); Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument…
Completely agree. I don't see many people in the React community advocating the use of DI though, so that's a plus. The DI in Angular made a little bit of sense because JS modules weren't very widespread back then. But now, with ES6 imports (and/or 'require') there's no need. We have real modules now, and they can be dynamically injected for testing purposes with something like inject-loader[0]. I think Angular and/o…
For example, oftentimes one has a class that may have an instance floating around. One does not want to instantiate it unnecessarily if it already exists oftentimes, and so the injector will handle that automatically if necessary by instantiating an instance if it doesn't exist already, allowing for efficient memory management of services. It also has a major benefit for facilitating easier patterns for testing & readability.
Angular 1's DI has a poor API signature, with the naive allowance of it through a hacky regex, and crappy duplication of string references for the regular usage with minification taken into account - Angular 2's is built much more solidly and without such hacks.
It should also be noted that using cjs for dynamic injection is a bit of a hack as well, since it is a non-standard syntax. Angular 2's DI is much more pure, as it could be split off into a standalone library with some build configuration with zero external dependencies other than perhaps an ES6 shim like core.js.
In the section on higher-order-components: var enhanceComponent = (Component) => class Enhance extends React.Component { render() { return ( ) } }; Shouldn't `{...this.state}` be considered an anti-pattern?
While i have read the oft-presented reasons for not using `this.state`, the arguments feel more academic to me than being based in practical examples. Your milage may vary, but in my experiences `this.state` is one of the more powerful features in React. To me, removing read access to component state also removes one of the more compelling reasons to include React into your codebase at all.
In the section on higher-order-components: var enhanceComponent = (Component) => class Enhance extends React.Component { render() { return ( ) } }; Shouldn't `{...this.state}` be considered an anti-pattern?