101–110 of 116 posts
Is there some sort of React component repository or something?
http://react.parts/web and http://react-components.com/
Earlier quoted context omitted.
>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? That it's stabler than most 1.0+ libraries is a good argument. Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automate…
> That it's stabler than most 1.0+ libraries is a good argument. What exactly do you mean by stability here? A 1.0 library (according to semver) is not allowed to break compatibility unless they bump to 2.0. Pre 1.0 version 0.14 is equivalent to version 14 if it had been 1.0. That's 14 breaking change in about 2 years. Or 7 a year. That's a lot. That's not stable.
The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? React seems kind of like an all-or-nothing approach. It seems like overkill if you just want t…
I have a question, why is dirty-checking so great? Whether it's Angular doing dirty-checking in the $digest cycle or React walking the virtual DOM and doing dirty-checking? Why not just subscribe to events and update things when the model changes? That would seem to be far more efficient, and also make clear the mapping of dependencies of views on data.
Wohoo! .getDOMNode() is finally gone! Edit: Haha, I just noticed that someone else was also happy about this. Also, now that classnames is standalone module, I recommend that people start using a standalone implementation of keyMirror (for flux) as well!
Would you mind explaining? As a jQuery believer, to me this looks like a selector method - getElementByID or something. I'm guessing this is against the whole idea of React.
Earlier quoted context omitted.
>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? That it's stabler than most 1.0+ libraries is a good argument. Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automate…
> That it's stabler than most 1.0+ libraries is a good argument. What exactly do you mean by stability here? A 1.0 library (according to semver) is not allowed to break compatibility unless they bump to 2.0. Pre 1.0 version 0.14 is equivalent to version 14 if it had been 1.0. That's 14 breaking change in about 2 years. Or 7 a year. That's a lot. That's not stable.
The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? React seems kind of like an all-or-nothing approach. It seems like overkill if you just want t…
React is really 2 things. One is an implementation of web components which makes it a competitor to Polymer and is is useful on almost any project. Secondly, React is an implementation of the Flux architecture (one-way data binding) which is most useful for SPAs, but doesn't disrupt a static site as much as Angular does.
Earlier quoted context omitted.
>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? That it's stabler than most 1.0+ libraries is a good argument. Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automate…
> That it's stabler than most 1.0+ libraries is a good argument. What exactly do you mean by stability here? A 1.0 library (according to semver) is not allowed to break compatibility unless they bump to 2.0. Pre 1.0 version 0.14 is equivalent to version 14 if it had been 1.0. That's 14 breaking change in about 2 years. Or 7 a year. That's a lot. That's not stable.
I mean “stable” by “takes 2 hours to update the code once in three months”. Are you building websites or rockets?
Earlier quoted context omitted.
>2. Those who care about compatibility a little bit but don't want a large version number. >React seems to fall into #2 here. Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you , cares a little about compatibility? React tea…
Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about…
It's about 20 core methods, not a giant lib like jQuery. From my experience, a medium sized project is adjusted to the changes in about two hours. Once every three months.
Is this a big deal in trade for progress?
Earlier quoted context omitted.
Right. I guess it really depends how people define "dirty checking". What I was trying to say is that at the end of the day you do diffing on some data structure: model in Angular and virtual Dom in React. Loop vs. one pass is an important distinction, agreed. But when we bring Angular we should be noted that Angular 2 doesn't do those checks in a loop but does comparisons in one pass only.
My biggest complaints about angular aren't really the dirty checking system that it uses (though one of them is a side effect). My biggest complaint is the weird dependency injection system that makes it difficult to track down where something comes from. It's better in 2, but still not as straight forward as React, where your child components are simply import/require statements that you can follow through to either…
It should also be noted that imports are orthogonal to the utility of DI. ES imports does not address the runtime dependency tree, and can certainly live alongside a tool such as DI - DI is for handling runtime dependency management, importing/exporting is more for handling initialization/compile time dependency management. Confusing the two is not understanding the problems they are meant to solve.
Angular 1's DI, while extremely convenient for testing, unfortunately does rely on a hacky implementation. Angular 2's DI system is extremely robust though, using the proposed ES7 decorator standard to more properly implement DI via IoC by using the services themselves (which are imported in) to fetch the appropriate instance - Angular 2's component system also makes it extremely easy to consume the injector with one line, or even creating new injectors to silo sectors of an application into runtime modules.
Angular 2 also espouses many of the ideas that React has pioneered in frontend web development - in fact, the Angular team would be quick to admit the faults present in Angular 1, which didn't have the benefit of the current state of HTML & JavaScript in the late '00s when it was conceived (ES module standard, annotations/decorators being a potential language feature, strong browser standards support across the major 4 browser vendors, etc.). Flux-like patterns can be easily implemented in Angular 2, and may see a surge in popularity given its popularity in the React ecosystem. Uni-directional data flow is at the core of Angular 2's component system.