The React digest – A hand-picked weekly selection of the best React JavaScript resources | Hacker News Reader

The React digest – A hand-picked weekly selection of the best React JavaScript resources

getrevue.co

83 pointsmdekuijper21 comments

The sign-up page is largely worthless -- here is their first issue (from today):

https://www.getrevue.co/profile/the-react-digest/archive/540...

There is also React.js Newsletter http://reactjsnewsletter.com

Someone fill me in - is React now the accepted awesome way to build front ends for single-page apps?

far past that. The discussion is now, what framework do we build react apps with. And if you're answer is Flux, you're wrong.

Can you elaborate on this?

I can! The idea of unidirectional dataflow is pretty good but the rest of the ideas in Flux aren't as good. For Facebook's implementation, I find making a change requires a bunch of related changes in a bunch of files and I don't like having stores chain.

If you stick all your data into a single big tree/store, you can inspect/serialize and pull off tricks like snapshotting, session recording, simple undo/redo, and time travelling debugging. I do my day to day development in clojurescript (re-frame) so I'm not necessarily up to date but I believe Redux is currently on top for doing this pattern in javascript land.

Redux IS Flux.

That's an important note, indeed. Flux is a pattern as well as a library that represents an implementation of the pattern. Redux is another implementation (and a better one at that, in my opinion.) Specifically regarding Greyrest's concerns about many changes across many files - this can be reduced substantially using Redux.

With all that said, I still wouldn't consider FluxJS a bad place to start, as it provides a very clear example of what Flux really is, but once you understand how the pattern works you'll understand where the implementation is lacking and how Redux can help with that.

My main issue with Redux is that it is incredibly verbose compared the alternatives.

Also one single state is great for simple-moderately complex apps but it gets horrible for ones not build from scratch to work with that dynamic.

Something like Alt I find to be the best of both worlds tbh.

Redux is "inspired by" Flux, but it's not Flux. One very big (and positive) difference: with Flux each store notifies the React components when it's updated, independently from the other stores.

This means that, if you update two stores with a single action, this will provoke two renders, the first one with inconsistent data between the two stores (in other words, there is no way to update all the stores atomically from the React components point of view).

Redux, instead, updates the whole store, and only then notifies the React components.

> The idea of unidirectional dataflow is pretty good

Yes, but it's a bog standard local bus or message queue. There's nothing even slightly innovative about this approach.

Just use redux, you won't regret it.

https://github.com/rackt/redux

Not quite - looking forward to when more people start exploring Angular 2 and seeing the things done wrong in React in comparison, it is looking like a juggernaut of a library in many aspects.

React is the best relatively stable library/framework we have now though. I would definitely recommend people to look into using it seriously if they had a chance to start fresh, and have recommended it to people learning development, as well as mentored some new developers in using it. Other than some wonky API design in some areas, it is relatively simple to pick up and use. The complexity gets shifted to app architecture, which is always difficult for many developers to wrestle with.

> seeing the things done wrong in React in comparison

Like...?

We can't know what's wrong yet. We'll see once people start using and exploring alternative frameworks. It's arrogant to think that React did everything correct. Even in React itself we've seen some evolution (React.createClass -> ES6 classes -> ?pure functions?).

But that's not what the post said - it said wrong in comparison.

Also your class creation example is just talking about language semantics. It'll never be a pure function (can't be - has to hold state) but it IS a pure object under the hood.

More or less IMO. React+Redux is a solid default choice for any UI. That said, I can't speak about Angular 2, but Ember has been integrating a lot of the good ideas from React with a focus on longer-term support and everything-just-works cohesion. Ember could be a great choice if you are, say, an enterprise which values such things. But a neat thing about React is it's becoming increasingly transparent---just a powerful structure for plain javascript and an optional HTML-like component rendering syntax. Also, Ember is strictly a web framework, where React is increasingly cross-platform.

just about, yes. it's not quite there yet, but as close as anything since Backbone in the early days, I might say.

React isn't a full solution to the single-page app; it's a very clever and efficient way to create UI components. For that role, it looks like the best solution at the moment.

What I'd like to know is how React and Rails should best interact and I can't seem to figure it out.

Should I ditch Rails altogether? But that doesn't make sense, right? Because React is a front-end thing and Rails is a whole framework. Should React replace Views in Rails then? If so, how? Should I just use Rails as a JSON Api then? In that case, should I not wait for Rails 5? Should I be using Redux, and if so should I be using Webpack? How do I integrate NPM and Webpack with a Rails project?

Aaaaargh. So many questions! :(

I've used react-rails as a way to use React components with low friction in rails views. However, its been a few years now since a significant percentage of rails developers have come to look at Rails as an API layer and use SPAs as the UI, regardless of what client-side framework you use.

Marketwise, Rails is on a long, slow decline. You should definitely broaden your horizons, even if Rails is going to be around for several years yet. You're probably going to see fewer "interesting" Rails projects come up, and a lot more legacy and "mature" applications. Elixir and Phoenix is where I'm putting my attention these days, but there's a lot of interesting work going on server-side these days as well.

Reply on news.ycombinator.com