Learn React.js in a weekend
nodecasts.ioI don't recommend learning Redux the first weekend you learn React. This would be akin to learning about Relativity the first weekend you learn Mechanics. I actually think it's detrimental to suggest beginners learn Redux alongside React because it unnecessarily steepens the learning curve.
Not that Redux is too complicated (it actually has a super simple API). Redux is a (fantastic!) tool you should use once your project is at a large enough scale that you need it. You can go a long way in vanilla React before you feel the pains that Redux (or Relay) solves. The React part of my current codebase is over 25k LoC and I still don't feel the need to throw Redux into the mix.
Take a peep at http://djcordhose.github.io/hh-react-conf-2016/redux-vs-rela...
If you're just starting out then first spend several weeks/months in vanilla React. Unless you need to learn Redux to work on a bigger codebase at a new job or something...
Qualification: I used to work on React Native at Facebook.
What stacks would you recommend for starting a React Native application of low complexity (like single man operation) and low-to-moderate complexity (like a several man seed-funded company)?
If you don't need a server then React Native should basically be your entire stack. :)
Since you do probably need a server, I don't have an incredibly educated answer for you but I use Node + Mongo on AWS because it's cheap, easy, entirely JS, and seems like it'll scale reasonably well (to some point).
I mean does an application being React Native change your opinion on using Redux or Relay?
It's really up to you. It's a tradeoff between spending additional effort on dev ops now (rather than product) versus building the technical debt that will be converting your app over later. If everyone on your team knows Redux then sure, start the app's architecture to scale to a huge team. If it'll significantly slow down product development then have everyone learn + convert later.
I'd err on the side of the latter (vanilla RN, Redux when you need it) to move fast on your product.
> I don't recommend learning Redux the first weekend you learn React.
Agree and so do others:
https://mobile.twitter.com/mjackson/status/74507491083006771...
Admittedly this may sound like "argument from authority", but I just mean that it's not an unpopular opinion. I've seen way too many people be too dogmatic about Redux. Core React is underrated.
Thanks for the advice.
I've been wanting to learn React for a while, but each time I start, I'm put off by the complexity it adds (compared to e.g., jQuery + vanilla JS). I soon will just jump in and learn to swim.
BTW, do folks use React for server-side apps as well? If so, is that common?
Also, I almost ROFL at the "axes might be logarithmic" in that graph's legend!
Sure thing!
You can definitely render your React code on the server and (distrubutedly + carefully) cache the result to make your initial page load blazingly fast. IMO it's more of an optimization though.
I don't personally use this feature since client-side rendered has been plenty fast enough for me so far.
Learning React is IMO one of the most impactful things I've ever done to be able to effectively build products, couldn't recommend it more!
Thanks for the detailed opinion. I'm just trying to relearn Jquery/Vanila JS myself and want to jump to react and a few other libraries. Seems like I shouldnt be that afraid
I'm putting together a React course right now and have specifically avoided Redux (& even server-side React). I don't want to get in the way of the a-ha moment when you see React components working together simply and cleanly
What would you recommend to do about the aspects React doesn't cover? (My sole use case is webapps and dynamic webpages)
I mean, React is only when you have an object and want to render an UI component, right? That's quite a small part of what even a simplest CRUD interface has to do (i.e. acquire the object from server and then try to keep it in sync with both server-maintained state and user feedback).
So https://productpains.com is entirely written in React and React Router (no Redux, yet).
I have a few wrapper components that know how to fetch various datas (a product, post, etc). They then pass this data into their children via props. When the user makes a mutation (vote, comment, post, etc) I'll let my server know to make the mutation and then do one of two things:
1. Optimistic: "Fake" the mutation using state until the server response comes back, then reload the data
2. Loading Indication: Give some sort of indication that the mutation is happening (eg. a spinner) and then when the server response comes back, reload the data
We don't currently update data live when there are changes on the server. This could be trivially implemented with polling. Or the more complicated solution would be to use a socket and subscribe to certain datas on the server which would get pushed to the client upon mutation. (see GraphQL Subscriptions! http://graphql.org/blog/subscriptions-in-graphql-and-relay/)
I.e. you suggest to use no library, but just ad-hoc DIY XHR/websocket/whatever-else-works to do what React doesn't?
I was asking exactly because I've already tried this and didn't like the process and results. Used the loading indication approach, with models having `pendingUpdate` flags. Basically, I felt that I'm writing ton of unnecessary code that had to be written only because things are too low-level. Like I was re-solving already solved problems.
React does the UI layer, but DIY data model + persistence layers aren't fun. What I'm looking for, is something like Angular's $resource (or its extensions) for React. Something that hides away the unnecessarily gory details (low-level XHR stuff, URL construction, maybe even data validation) behind a programmer-friendly API facade (`Item.save`), plays well with React and those fluxish patterns, yet doesn't enforce any special requirements on the server-side tech (i.e. can be used with existing Django/Rails/PHP backends).
Question for people who learn by video rather than text based guides - why do you find it more effective?
I have trouble following someone else's pace in a video (or audio for that matter). I also like to be able to copy and paste code into my editor. Navigation to particular sub sections is easier too.
I get different things from videos than I do text. From a video, I get a "why" and a "how" most often, whereas from text I get a "what". Obviously text can represent why and how, but I feel there's something lost going from screencap to screencap that is perfectly captured in video about the process of getting from point A to point B. Additionally, most blog posts don't publish the mistakes (let's try this thing! crap it didn't work, here's why. This is especially true as a result of a question.) but you can very easily convey that type of information in video by just showing it not working. The pacing thing is totally a valid concern and I find myself watching youtube videos at 1.5 or 2x speed to consume the content.
I use a combination of both, and I'll scrub a video a lot to see a concept.
For me, hearing a description will often come with some emotional cues. Stuff like, "Now this is cool..." or "Oof, forgot the iterator..." help me learn where I should be paying attention.
Text often has a hard time conveying the same set of information. Sure, you can type 'watch out!' in a yellow box around some text, but my ape brain doesn't pick those up as the same as watching (or listening) to another ape brain make the mistake or exclaim in delight.
Sometimes it's seeing the workflow. Sometimes it's seeing the outcome without having to run a hello-world yourself. But I think mostly it's because videos give a much better overall topology quicker than reading. For example, I'll watch a screencast end-to-end, and then I'll begin the project and start to go through it slower, knowing which branches of the text tutorial are important because I've seen the complete picture.
Maybe the problem is that you are assuming others have no trouble. Videos tend to pack more stuff in a shorter amount of time and new concepts require extra effort. I have heard that some "learn better by video rather than text, etc..." but doubt it is true.
I always liked Railscasts and the companion/transcribed "Asciicasts".
I think the video format is a kind of forcing function in terms of the presenter really explaining things (if they aren't just reading off the screen). Which in turn made the transcript great to read.
My brain simply absorbs information at a faster rate with video/audio than reading.
For me the thing I'm finding most annoying is how many errors I get just setting up this stuff, whether it's Angular or React or something else.
I'm on Windows though so I assume a lot of my issues stem from the tutorial authors assuming they are talking to a purely *nix crowd.
Something about react life cycles, in a daily sharing video: https://www.youtube.com/watch?v=vEf8c1-WBBs
Is this all paid content?
Nope! Everything is free except the first link!
How about: RTFM https://facebook.github.io/react/docs/getting-started.html
I don't get the react hype anyways. Writing inline HTML in JavaScript seems so weird to me (JSX).
The argument (among others) is that if you're going to be using if/else, for loops, and all that in a templating language you might as well use a full-featured language like JavaScript... (youtube timestamp: https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=4m13s)
or, you know, just write the app in pure javascript and still reap the benefits of [2-3x faster than React] virtual dom. though i'm a bit biased [1] ;)
Meh since when is computational performance really a bottleneck? Do you find your site is loading seconds too slowly because JS is executing? I sure don't.
On today's machines the much larger bottleneck is how fast and easily you can iterate on product at scale which is a problem that React is a fantastic solution for.
> Meh since when is computational performance really a bottleneck?
Ever used a phone that wasn't < 6 months old to browse the modern web?
> at scale
React is a front-end framework. The only "scale" that exists in its world is the fat DOM you generate and how fast it can mutate it. From that perspective, it sucks at scale (take a look at Preact and Inferno). Your iteration speed depends on good app architecture, not a specific framework. React Native does sound like a good perk, but likely isnt useful enough to make anything you cannot do anyway in HTML5.
Scale in terms of number of engineers and app size, not users
> number of engineers
can't this be said about any popular framework? "it scales because everyone knows it"
> app size
what specifically makes React scale better with app size than any other properly componentized architecture?
It doesn't scale because everyone knows it. It scales because React by nature isolates business logic into components so that for the most part 100 engineers can simultaneously work on the same product and be confident they aren't breaking stuff. (Or realize they are through merge conflicts)
> "properly componentized"
With React, 100 engineers don't have to know how to "properly componentize" things because it's already baked into the framework. You can't really write React code without proper componentization.
> React by nature isolates business logic into components
The essence is simply this:
...which can work with any view layer and the same 100 engineers. Especially if the model is an API with business logic around some immutable stream/state. The concept is simple enough to be described in one sentance :)function MyView(model) { return template; }> don't have to know how to "properly componentize" things
I think you're overstating how difficult this problem is or forgetting that React's API must still be learned from documentation and examples.
What about state within a component? How do you encapsulate that state so that other components can't muck with it? What about passing data to that component? What about type checking that data passed in in debug mode? What about a formal API for components to talk to one another? What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?
React has answers to all these questions and so much more. Answers that very smart people have spent years coming up with.
Sure you could reinvent the wheel and build all that into your custom component framework, but then you may as well just use React.
I will address these with respect to domvm [1]
> What about state within a component? How do you encapsulate that state so that other components can't muck with it?
Solved.
> What about passing data to that component?
Solved.
> What about type checking that data passed in in debug mode?
Could be solved if i rewrote in TypeScript. But this has never been a problematic issue in 10k+ LOC apps.
> What about a formal API for components to talk to one another?
Yep.
> What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?
Obviously, that's what virtual dom is.
In addition to all of this and much more, materialized views are independently refreshable, can be composed between disjoint components. There are async lifecycle hooks, a router, mutation observers, ajax sugar.
All of it is 17k min, requires no special tooling or IDE to write, is isomorphic and is 2-3x faster than React.
I have no doubt that React brings a lot to the table, but I hesitate to treat it as the final word in frontend frameworks for all the above reasons.
On mobile, it matters a lot, especially older/low-end Android phones.
Actually I do find javascript making many sites that are ultimately just displaying text, so slow as to be unusable.
How do you know it's the JS executing and not network time or the result of a poor infra decision?
Because it works great with JS turned off, and you can measure what is using your CPU an d what it is doing and how much time it is taking (also you can measure the network).
JSX is entirely optional and it is easy to use React without it. (e.g., http://ludovf.net/reactbook/blog/reactjs-without-jsx-part2.h...)
(I hope the comment doesn't indicate that you think the interesting thing about React is JSX.)
Everyone has different mechanisms for learning. As someone who learns from manuals, tutorials, and videos simultaneously, a new technology presented as a wall of text can seem impenetrable until I've watched another human make something happen.
Then, I can loop back to that text armed with a little context. Videos are often examples of how to develop with the technology outside of a bubble. (Using React? Consider setting up webpack!) That seems to be missing from manuals sometimes.
Separating html out into a separate file/template always seemed weird to me. In every JS Framework HTML and Javascript are tightly coupled. JSX is also javascript, not HTML.
Yeah, the jsx bit is weird to start with, the best bit is changing data diffs the DOM and updates it for you.
However, unless building a madly complex UI I've decided it's best avoided; mostly because now that I can build super complex UIs I probably will rather than simplify things that can work in a progressively enhanced way.
haha that's the 5th link in the blog post
React is 1 hr at the most to fully learn and get a good grasp...